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
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
29 matches
Mail list logo
