Re: Fix LTO bootstrap on Windows (PR lto/85574)

2021-01-28 Thread Richard Biener via Gcc-patches
On Thu, Jan 28, 2021 at 9:35 AM Eric Botcazou wrote: > > The last fix made for PR lto/85574 introduced a comparison of executables and > this cannot directly work on Windows because they are timestamped. Moreover > nobody sets $(exeext) at top level, at least on MinGW, so you get a weird >

Fix LTO bootstrap on Windows (PR lto/85574)

2021-01-28 Thread Eric Botcazou
The last fix made for PR lto/85574 introduced a comparison of executables and this cannot directly work on Windows because they are timestamped. Moreover nobody sets $(exeext) at top level, at least on MinGW, so you get a weird behavior because some tools add the implicit .exe suffix and

Fix LTO bootstrap

2019-10-10 Thread Jan Hubicka
Hi, enabling inlining triggered lifetime-dse issue with symbol_table constructor. Bootstrapped/regtested x86_64-linux * cgraph.c (symbol_table_test::symbol_table_test): Use ggc_alloc rather than ggc_alloc_cleared to alloc symbol table. * toplev.c (general_init): Likewise.

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-09 Thread Christophe Lyon
Hi, On 7 January 2017 at 12:43, Richard Biener wrote: > On January 6, 2017 8:00:21 PM GMT+01:00, Jakub Jelinek > wrote: >>On Fri, Jan 06, 2017 at 05:58:05PM +0100, Christophe Lyon wrote: >>> > Trying now: >>> > >>> > 2017-01-06 Jakub Jelinek

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-07 Thread Richard Biener
On January 6, 2017 8:00:21 PM GMT+01:00, Jakub Jelinek wrote: >On Fri, Jan 06, 2017 at 05:58:05PM +0100, Christophe Lyon wrote: >> > Trying now: >> > >> > 2017-01-06 Jakub Jelinek >> > >> > * Makefile.in (CFLAGS, CPPFLAGS, LDFLAGS): Remove -fno-lto.

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-06 Thread Jakub Jelinek
On Fri, Jan 06, 2017 at 05:58:05PM +0100, Christophe Lyon wrote: > > Trying now: > > > > 2017-01-06 Jakub Jelinek > > > > * Makefile.in (CFLAGS, CPPFLAGS, LDFLAGS): Remove -fno-lto. > > (NOLTO_FLAGS): New variable. > > (ALL_CFLAGS): Use it. > >

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-06 Thread Christophe Lyon
On 6 January 2017 at 17:46, Jakub Jelinek wrote: > On Fri, Jan 06, 2017 at 05:33:03PM +0100, Jakub Jelinek wrote: >> On Fri, Jan 06, 2017 at 05:12:54PM +0100, Christophe Lyon wrote: >> > This makes all my builds fail. >> > (The *linux* ones are broken after Alexandre's pragma,

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-06 Thread Jakub Jelinek
On Fri, Jan 06, 2017 at 05:33:03PM +0100, Jakub Jelinek wrote: > On Fri, Jan 06, 2017 at 05:12:54PM +0100, Christophe Lyon wrote: > > This makes all my builds fail. > > (The *linux* ones are broken after Alexandre's pragma, and > > this commit breaks the remaining bare-metal configurations). > >

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-06 Thread Jakub Jelinek
On Fri, Jan 06, 2017 at 05:12:54PM +0100, Christophe Lyon wrote: > This makes all my builds fail. > (The *linux* ones are broken after Alexandre's pragma, and > this commit breaks the remaining bare-metal configurations). > make[2]: Entering directory >

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-06 Thread Christophe Lyon
O bootstraps on x86_64-linux-gnu, can bootstrap on >> ppc64le-redhat-linux >> and survives regression tests. >> >> Ready to be installed? >> Martin > >> >From 67a3ccd99963ac19cbaebf17453cb51819c7bf1d Mon Sep 17 00:00:00 2001 >> From: marxin <mli...@su

Re: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-06 Thread Jakub Jelinek
> Ready to be installed? > Martin > >From 67a3ccd99963ac19cbaebf17453cb51819c7bf1d Mon Sep 17 00:00:00 2001 > From: marxin <mli...@suse.cz> > Date: Thu, 5 Jan 2017 17:18:27 +0100 > Subject: [PATCH] Fix lto-bootstrap (PR bootstrap/79003). > > gcc/ChangeLog: > > 2017-

[PATCH] Fix lto-bootstrap (PR bootstrap/79003).

2017-01-06 Thread Martin Liška
e: Thu, 5 Jan 2017 17:18:27 +0100 Subject: [PATCH] Fix lto-bootstrap (PR bootstrap/79003). gcc/ChangeLog: 2017-01-05 Martin Liska <mli...@suse.cz> PR bootstrap/79003 * lra-constraints.c: Rename invariant to lra_invariant. * predict.c (set_even_probabilities): Initialize e to NULL

Fix lto-bootstrap ICE with decl merging disabled

2015-12-27 Thread Jan Hubicka
Hi, this seems to be last ICE I can reproduce with decl and tree merging disabled. ipa-visibility assumes that comdat groups are either all local or all external. With decl merging disabled we can have external aliases of comdat symbols. We should fix the visibility of transparent aliases, but

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-18 Thread Teresa Johnson
On Sat, Nov 16, 2013 at 12:33 AM, Jan Hubicka hubi...@ucw.cz wrote: When testing with -freorder-blocks-and-partition enabled, I hit a verification failure in an LTO profiledbootstrap. Edge forwarding performed when we went into cfg layout mode after bb reordering (during compgotos) created a

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-18 Thread Steven Bosscher
On Mon, Nov 18, 2013 at 3:53 PM, Teresa Johnson wrote: From a bb layout perspective it seems like it would be beneficial to do compgotos before layout. Was the current position just to try to reduce compile time by keeping the block unified as long as possible? It was more a hack that got out

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-18 Thread Teresa Johnson
On Mon, Nov 18, 2013 at 7:34 AM, Steven Bosscher stevenb@gmail.com wrote: On Mon, Nov 18, 2013 at 3:53 PM, Teresa Johnson wrote: From a bb layout perspective it seems like it would be beneficial to do compgotos before layout. Was the current position just to try to reduce compile time by

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-18 Thread Jan Hubicka
2013-11-18 Teresa Johnson tejohn...@google.com * gcc/cfgrtl.c (cfg_layout_initialize): Assert if we try to go into cfglayout after bb reordering. * gcc/passes.def: Move compgotos before bb reordering since it goes into cfglayout. This seems resonable to

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-18 Thread Jeff Law
On 11/18/13 12:33, Teresa Johnson wrote: On Mon, Nov 18, 2013 at 7:34 AM, Steven Bosscher stevenb@gmail.com wrote: On Mon, Nov 18, 2013 at 3:53 PM, Teresa Johnson wrote: From a bb layout perspective it seems like it would be beneficial to do compgotos before layout. Was the current

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-18 Thread Teresa Johnson
On Mon, Nov 18, 2013 at 12:23 PM, Jeff Law l...@redhat.com wrote: On 11/18/13 12:33, Teresa Johnson wrote: On Mon, Nov 18, 2013 at 7:34 AM, Steven Bosscher stevenb@gmail.com wrote: On Mon, Nov 18, 2013 at 3:53 PM, Teresa Johnson wrote: From a bb layout perspective it seems like it

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-16 Thread Jan Hubicka
When testing with -freorder-blocks-and-partition enabled, I hit a verification failure in an LTO profiledbootstrap. Edge forwarding performed when we went into cfg layout mode after bb reordering (during compgotos) created a situation where a hot block was then dominated by a cold block and

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-16 Thread Teresa Johnson
On Sat, Nov 16, 2013 at 12:33 AM, Jan Hubicka hubi...@ucw.cz wrote: When testing with -freorder-blocks-and-partition enabled, I hit a verification failure in an LTO profiledbootstrap. Edge forwarding performed when we went into cfg layout mode after bb reordering (during compgotos) created a

Re: [PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-16 Thread Jan Hubicka
Note I haven't done an extensive check to see if compgotos is the only phase that goes back into cfglayout mode after bb reordering is done, that's just the one that hit this. Eventually it might be good to prevent going into cfglayout mode after bb reordering. Can we just try to abort when

[PATCH] Fix lto bootstrap verification failure with -freorder-blocks-and-partition

2013-11-15 Thread Teresa Johnson
When testing with -freorder-blocks-and-partition enabled, I hit a verification failure in an LTO profiledbootstrap. Edge forwarding performed when we went into cfg layout mode after bb reordering (during compgotos) created a situation where a hot block was then dominated by a cold block and was

[PATCH] Fix LTO bootstrap

2013-02-08 Thread Richard Biener
This fixes LTO bootstrap which, after the IRA changes to properly use loop_optimizer_init () and friends, now detects that we may in fact have invalidated dominator information (and formerly used this invalid dominator information to build up loops via flow_loops_find - oops). LTO bootstrap in

[PATCH] Fix LTO bootstrap (PR54876)

2012-10-10 Thread Richard Biener
The previous fix for clearing EXPR_LOCATION (and thus LOCATION_BLOCK) from jump functions was incomplete as it didn't consider sub-expressions. Fixed as follows. LTO bootstrapped on x86_64-unknown-linux-gnu, applied to trunk. Richard. 2012-10-10 Richard Biener rguent...@suse.de PR

[PATCH] Fix lto-bootstrap issue (one of them)

2012-09-25 Thread Richard Guenther
The following fixes the TREE_ADDRESSABLE issue during LTO bootstrap. We fail to merge all symbols because 'first' may no longer be 'first'. Committed as obvious. LTO bootstrap is still broken for me: /tmp/ccXpATTw.ltrans19.ltrans.o: In function `is_ctor_or_dtor.17240':

Re: [PATCH] Fix LTO bootstrap on i686-linux (problem with two Ldebug_info0 labels; PR bootstrap/48148)

2011-04-08 Thread Jason Merrill
On 04/05/2011 10:19 AM, Jakub Jelinek wrote: i686-linux LTO bootstrap currently fails, because in one partition we emit .Ldebug_info0 label twice. The problem is that resolve_addr for call_site support attempts to force_decl_die external function decls, and at least with LTO that in turn can

Re: [PATCH] Fix LTO bootstrap on i686-linux (problem with two Ldebug_info0 labels; PR bootstrap/48148)

2011-04-08 Thread Richard Guenther
On Fri, 8 Apr 2011, Jakub Jelinek wrote: On Fri, Apr 08, 2011 at 01:58:14PM -0400, Jason Merrill wrote: On 04/05/2011 10:19 AM, Jakub Jelinek wrote: i686-linux LTO bootstrap currently fails, because in one partition we emit .Ldebug_info0 label twice. The problem is that resolve_addr for

[PATCH] Fix LTO bootstrap on i686-linux (problem with two Ldebug_info0 labels; PR bootstrap/48148)

2011-04-05 Thread Jakub Jelinek
Hi! i686-linux LTO bootstrap currently fails, because in one partition we emit .Ldebug_info0 label twice. The problem is that resolve_addr for call_site support attempts to force_decl_die external function decls, and at least with LTO that in turn can attempt to create new type DIEs, in this

Re: [PATCH] Fix LTO bootstrap on i686-linux (problem with two Ldebug_info0 labels; PR bootstrap/48148)

2011-04-05 Thread Nathan Froyd
On Tue, Apr 05, 2011 at 04:19:39PM +0200, Jakub Jelinek wrote: + for (i = 0; i VEC_length (deferred_locations, deferred_locations_list); i++) +{ + add_location_or_const_value_attribute ( + VEC_index (deferred_locations, deferred_locations_list, i)-die, + VEC_index

Re: [PATCH] (partially) fix lto bootstrap (PR bootstrap/48148)

2011-04-04 Thread H.J. Lu
On Fri, Apr 1, 2011 at 2:18 PM, Jakub Jelinek ja...@redhat.com wrote: Hi! richi's lto-cgraph.c change actually didn't do anything, because DECL_ABSTRACT_ORIGIN is still NULL there, see PR for details. This patch instead doesn't try to force dies for DECL_ABSTRACT_ORIGIN DECL_EXTERNAL decls,