From patchwork Fri Aug 26 14:47:43 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 111791 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 7194EB6F72 for ; Sat, 27 Aug 2011 00:49:28 +1000 (EST) Received: (qmail 22956 invoked by alias); 26 Aug 2011 14:49:26 -0000 Received: (qmail 22947 invoked by uid 22791); 26 Aug 2011 14:49:25 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 26 Aug 2011 14:49:11 +0000 Received: (qmail 23590 invoked from network); 26 Aug 2011 14:49:10 -0000 Received: from unknown (HELO ?84.152.221.63?) (bernds@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Aug 2011 14:49:10 -0000 Message-ID: <4E57B20F.7000307@codesourcery.com> Date: Fri, 26 Aug 2011 16:47:43 +0200 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110801 Lightning/1.0b3pre Thunderbird/3.1.11 MIME-Version: 1.0 To: GCC Patches Subject: bb partitioning vs optimize_function_for_speed_p Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org In rest_of_reorder_blocks, we avoid reordering if !optimize_function_for_speed_p. However, we still call insert_section_bounary_note, which can cause problems because now, if we have a sequence of HOT-COLD-HOT blocks, the second set of HOT blocks will end up in the cold section. This causes assembler failures when using exception handling (subtracting labels from different sections). Unfortunately, the only way I have of reproducing it is to apply a 67-patch quilt tree backporting the preliminary shrink-wrapping patches to gcc-4.6; then we get FAIL: g++.dg/tree-prof/partition2.C compilation, -Os -fprofile-use However, the problem is reasonably obvious. Bootstrapped and currently testing in the aforementioned 4.6 tree. Ok for trunk after testing there? Bernd * bb-reorder.c (insert_section_boundary_note): Only do it if we reordered the blocks; i.e. not if !optimize_function_for_speed_p. Index: gcc/bb-reorder.c =================================================================== --- gcc/bb-reorder.c (revision 178030) +++ gcc/bb-reorder.c (working copy) @@ -1965,8 +1965,11 @@ insert_section_boundary_note (void) rtx new_note; int first_partition = 0; - if (flag_reorder_blocks_and_partition) - FOR_EACH_BB (bb) + if (!flag_reorder_blocks_and_partition + || !optimize_function_for_speed_p (cfun)) + return; + + FOR_EACH_BB (bb) { if (!first_partition) first_partition = BB_PARTITION (bb);