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
> behavi
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 others
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.
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
>>> >
>>> > * Makefile.in (CFLAGS, CPPFLAG
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.
>> > (NOLTO_FLAGS): New varia
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.
> > * configure.ac (nol
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, and
>> > this commit
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).
> > ma
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
> `/tmp/3119026_6.tmpdir/aci-gcc-fsf/builds/gcc
86_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
>> Date: Thu, 5 Jan 201
gt;
> Ready to be installed?
> Martin
> >From 67a3ccd99963ac19cbaebf17453cb51819c7bf1d Mon Sep 17 00:00:00 2001
> From: marxin
> Date: Thu, 5 Jan 2017 17:18:27 +0100
> Subject: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).
>
> gcc/ChangeLog:
>
> 2017-01-05 Martin Lis
17 17:18:27 +0100
Subject: [PATCH] Fix lto-bootstrap (PR bootstrap/79003).
gcc/ChangeLog:
2017-01-05 Martin Liska
PR bootstrap/79003
* lra-constraints.c: Rename invariant to lra_invariant.
* predict.c (set_even_probabilities): Initialize e to NULL.
libdecnumber/ChangeLog:
2017-01-05 Mart
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 that
On Mon, Nov 18, 2013 at 12:23 PM, Jeff Law wrote:
> On 11/18/13 12:33, Teresa Johnson wrote:
>>
>> On Mon, Nov 18, 2013 at 7:34 AM, Steven Bosscher
>> 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
On 11/18/13 12:33, Teresa Johnson wrote:
On Mon, Nov 18, 2013 at 7:34 AM, Steven Bosscher 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
redu
> 2013-11-18 Teresa Johnson
>
> * 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 me, but I can't a
On Mon, Nov 18, 2013 at 7:34 AM, Steven Bosscher 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 keeping the bloc
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 ou
On Sat, Nov 16, 2013 at 12:33 AM, Jan Hubicka 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 situatio
> 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 whe
On Sat, Nov 16, 2013 at 12:33 AM, Jan Hubicka 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 situatio
> 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 a
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 the
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 st
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
PR middle-end/54876
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':
ccXpATTw.ltrans19.o:(.tex
Hi,
On Fri, 8 Apr 2011, Richard Guenther wrote:
> > > Sounds like this comment needs to be updated if there can be types
> > > on the list as well.
> >
> > On a closer look, this seems to be because LTO messes up types
> > terribly, struct cpp_options's lang field doesn't have enum c_lang
> >
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
> > >resol
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 call_site support attempts to force_decl
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 att
On Tue, Apr 05, 2011 at 02:06:14PM -0700, Nathan Froyd wrote:
> 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 (
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
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 case
On Fri, Apr 1, 2011 at 2:18 PM, Jakub Jelinek 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, as dwarf2ou
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, as dwarf2out isn't prepared to handle them.
Bootstrapped/regtested on x86_6
35 matches
Mail list logo
