From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 35728 invoked by alias); 2 Nov 2015 21:04:21 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 35715 invoked by uid 89); 2 Nov 2015 21:04:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: gate.crashing.org Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Mon, 02 Nov 2015 21:04:17 +0000 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.13.8) with ESMTP id tA2L44aj011001; Mon, 2 Nov 2015 15:04:05 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id tA2L44VL010999; Mon, 2 Nov 2015 15:04:04 -0600 Date: Mon, 02 Nov 2015 21:04:00 -0000 From: Segher Boessenkool To: Alan Lawrence Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH 3/4] bb-reorder: Add -freorder-blocks-algorithm= and wire it up Message-ID: <20151102210403.GB9592@gate.crashing.org> References: <56377569.7010904@arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56377569.7010904@arm.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00127.txt.bz2 On Mon, Nov 02, 2015 at 02:38:33PM +0000, Alan Lawrence wrote: > On 23/09/15 23:06, Segher Boessenkool wrote: > >This adds an -freorder-blocks-algorithm=[simple|stc] flag, with "simple" > >as default. For -O2 and up (except -Os) it is switched to "stc" instead. > >Targets that never want STC can override this. This changes > >-freorder-blocks > >to be on at -O1 and up (was -O2 and up). > > > >In effect, the changes are for -O1 (which now gets "simple" instead of > >nothing), -Os (which now gets "simple" instead of "stc", since STC results > >in much bigger code), and for targets that wish to never use STC (not in > >this patch though). > > > > > >2015-09-23 Segher Boessenkool > > > > * bb-reorder.c (reorder_basic_blocks): Use the algorithm selected > > with flag_reorder_blocks_algorithm. > > * common.opt (freorder-blocks-algorithm=): New flag. > > (reorder_blocks_algorithm): New enum. > > * flag-types.h (reorder_blocks_algorithm): New enum. > > * opts.c (default_options_table): Use -freorder-blocks at -O1 and up, > > and -freorder-blocks-algorithm=stc at -O2 and up (not at -Os). > > I'm a bit puzzled as to why nobody else has been seeing this, as it's been > happening to me as part of building gcc on x86_64, but since this patch > I've been seeing an ICE in vec::operator[] in reorder_basic_blocks_simple, > building libitm/beginend.cc. Preprocessed source attached, command line > reduced to: > > $ /work/alalaw01/build/./gcc/xg++ -B/work/alalaw01/build/./gcc/ -mrtm -O1 > -g -m32 -c temp.ii > /work/alalaw01/src/gcc/libitm/beginend.cc: In static member function > ‘static uint32_t GTM::gtm_thread::begin_transaction(uint32_t, const > gtm_jmpbuf*)’: > /work/alalaw01/src/gcc/libitm/beginend.cc:400:1: internal compiler error: > in operator[], at vec.h:714 > } > ^ > 0x1310783 vec::operator[](unsigned int) > /work/alalaw01/src/gcc/gcc/vec.h:714 > 0x1310783 reorder_basic_blocks_simple > /work/alalaw01/src/gcc/gcc/bb-reorder.c:2322 That seems to be happening in the FOR_EACH_BB_FN then? Or one of the EDGE_SUCCs? I cannot match up that line # with anything. Both cases suggest things are broken before already. > 0x1310783 reorder_basic_blocks > /work/alalaw01/src/gcc/gcc/bb-reorder.c:2450 > 0x1310783 execute > /work/alalaw01/src/gcc/gcc/bb-reorder.c:2551 > > Compilation succeeds at -O2 (instead of -O1). reorder_basic_blocks_simple isn't used at -O2 (it uses STC instead). I'll have a look at this wednesday. Segher