* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
@ 2014-08-10 15:41 ` sven.c.dack at virginmedia dot com
2014-08-10 15:46 ` sven.c.dack at virginmedia dot com
` (57 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-10 15:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #1 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
I have worked around the problem by adding a line to 'bootstrap-lto.mk' and to
let it use a script for comparing object files based only on their disassembled
code.
I assume when the disassembled output of the object files matches then it
should not matter much how it got there. It is not perfect, but it is better
than not to bootstrap at all.
I am going to attach a patch for those who are interested.
Sven
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
2014-08-10 15:41 ` [Bug bootstrap/62077] " sven.c.dack at virginmedia dot com
@ 2014-08-10 15:46 ` sven.c.dack at virginmedia dot com
2014-08-11 8:51 ` rguenth at gcc dot gnu.org
` (56 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-10 15:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack <sven.c.dack at virginmedia dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sven.c.dack at virginmedia dot com
--- Comment #2 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
Created attachment 33285
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33285&action=edit
Changes the way 'bootstrap-lto.mk' compares object files
The patch changes how 'bootstrap-lto.mk' compares object files by adding a new
script 'compare-disassembly', which only compares the disassembled output of
two object files.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
2014-08-10 15:41 ` [Bug bootstrap/62077] " sven.c.dack at virginmedia dot com
2014-08-10 15:46 ` sven.c.dack at virginmedia dot com
@ 2014-08-11 8:51 ` rguenth at gcc dot gnu.org
2014-08-11 10:07 ` rguenth at gcc dot gnu.org
` (55 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-11 8:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |build, lto
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-08-11
CC|richard.guenther at gmail dot com |rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Btw, I can confirm the issue for the 4.9 branch (with release checking).
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (2 preceding siblings ...)
2014-08-11 8:51 ` rguenth at gcc dot gnu.org
@ 2014-08-11 10:07 ` rguenth at gcc dot gnu.org
2014-08-11 10:19 ` venkataramanan.kumar at amd dot com
` (54 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-11 10:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-*-*
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Also fails with the 4.9.0 release on x86_64.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (3 preceding siblings ...)
2014-08-11 10:07 ` rguenth at gcc dot gnu.org
@ 2014-08-11 10:19 ` venkataramanan.kumar at amd dot com
2014-08-12 7:24 ` sven.c.dack at virginmedia dot com
` (53 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-11 10:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #5 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
(In reply to Richard Biener from comment #4)
> Also fails with the 4.9.0 release on x86_64.
Also fails with the GCC 4.9 on Aarch64 target.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (4 preceding siblings ...)
2014-08-11 10:19 ` venkataramanan.kumar at amd dot com
@ 2014-08-12 7:24 ` sven.c.dack at virginmedia dot com
2014-08-12 7:47 ` sven.c.dack at virginmedia dot com
` (52 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-12 7:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #6 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
It seems the problem is caused by the use of the jobserver. Changing
bootstrap-lto.mk from:
...
STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
...
to:
...
STAGE2_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 -ffat-lto-objects
STAGE3_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1 -ffat-lto-objects
...
Results in a success without using an additional compare script:
...
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
Comparison successful.
...
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (5 preceding siblings ...)
2014-08-12 7:24 ` sven.c.dack at virginmedia dot com
@ 2014-08-12 7:47 ` sven.c.dack at virginmedia dot com
2014-08-12 8:03 ` pinskia at gcc dot gnu.org
` (51 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-12 7:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack <sven.c.dack at virginmedia dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #33285|0 |1
is obsolete| |
--- Comment #7 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
Created attachment 33299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33299&action=edit
Removes the use of the jobserver from bootstrap-lto.mk
The patch changes bootstrap-lto.mk to use a single, unpartitioned stream
instead of the jobserver.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (6 preceding siblings ...)
2014-08-12 7:47 ` sven.c.dack at virginmedia dot com
@ 2014-08-12 8:03 ` pinskia at gcc dot gnu.org
2014-08-12 8:10 ` rguenther at suse dot de
` (50 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: pinskia at gcc dot gnu.org @ 2014-08-12 8:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sven C. Dack from comment #7)
> Created attachment 33299 [details]
> Removes the use of the jobserver from bootstrap-lto.mk
>
> The patch changes bootstrap-lto.mk to use a single, unpartitioned stream
> instead of the jobserver.
This patch makes sense from a reproducibility point of view too.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (7 preceding siblings ...)
2014-08-12 8:03 ` pinskia at gcc dot gnu.org
@ 2014-08-12 8:10 ` rguenther at suse dot de
2014-08-12 8:23 ` venkataramanan.kumar at amd dot com
` (49 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenther at suse dot de @ 2014-08-12 8:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #10 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 12 Aug 2014, trippels at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |trippels at gcc dot gnu.org
>
> --- Comment #9 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
> (In reply to Andrew Pinski from comment #8)
> > (In reply to Sven C. Dack from comment #7)
> > > Created attachment 33299 [details]
> > > Removes the use of the jobserver from bootstrap-lto.mk
> > >
> > > The patch changes bootstrap-lto.mk to use a single, unpartitioned stream
> > > instead of the jobserver.
> >
> > This patch makes sense from a reproducibility point of view too.
>
> But it will increase the build-time enormously.
Yeah, and that it triggers a comparison error sounds bogus. It just
triggers the use of a makefile for building the _LTRANS_ objects.
Thus it shouldn't have an effect on the object files we compare
(especially if the actual final cc1 object does _not_ miscompare
and thus we don't see a stage2/3 miscompile).
Richard.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (8 preceding siblings ...)
2014-08-12 8:10 ` rguenther at suse dot de
@ 2014-08-12 8:23 ` venkataramanan.kumar at amd dot com
2014-08-12 9:20 ` rguenth at gcc dot gnu.org
` (48 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-12 8:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #11 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
I am also trying to fix LTO bootstrap compare failure in Aarch64.
Bootstrap compare failure is not occurring in GCC FSF trunk (tested on aarch64
as well as x86_64 machine). Now I am doing one more round of bisecting to see
which revision fixes this (or) first time compare not seen.
Also I tried to recompile gimple.o which was miscomparing and also dump the
gimple and IPA IR. I found that in GCC trunk there are no differences between
stage2 and stage3 dumps.
But with GCC 4.9 there are some differences,
Stage2 (prev-gcc) vs stage3 (gcc)
Very first dump file is gimple.c.001t.tu
The number of @numbers are more in stage2
@103184 identifier_node strg: debug_ready_dispatch lngt: 20
Stage3
@103169 identifier_node strg: debug_ready_dispatch lngt: 20
Also gimple.c.048i.inline showed differences in Min size.
(--Snip--)
< min size: 6
---
> min size: 0
6590c6590
< min size: 14
---
> min size: 0
6607c6607
< min size: 28
(--Snip--)
In gimple-fold.c.000i.cgraph
(--Snip--)
< _Z25gimple_build_omp_continueP9tree_nodeS0_/761
(gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff7ebda548
---
> _Z25gimple_build_omp_continueP9tree_nodeS0_/761
> (gimple_build_omp_continue(tree_node*, tree_node*)) @0x3ff92b5a548
28865c28865
(--Snip--)
why do these dumps show differences? The other tree optimization dumps don't
show any difference.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (9 preceding siblings ...)
2014-08-12 8:23 ` venkataramanan.kumar at amd dot com
@ 2014-08-12 9:20 ` rguenth at gcc dot gnu.org
2014-08-12 10:52 ` venkataramanan.kumar at amd dot com
` (47 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-12 9:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so there is one thing that changed (but only very recently) on trunk which
is improved hashing of SCCs and thus more consistent ordering.
Especially I'm talking about the fact that at compile-time (!) we sort
via
static int
scc_entry_compare (const void *p1_, const void *p2_)
{
const scc_entry *p1 = (const scc_entry *) p1_;
const scc_entry *p2 = (const scc_entry *) p2_;
if (p1->hash < p2->hash)
return -1;
else if (p1->hash > p2->hash)
return 1;
return 0;
}
static hashval_t
hash_scc (struct streamer_tree_cache_d *cache, unsigned first, unsigned size)
{
/* Compute hash values for the SCC members. */
for (unsigned i = 0; i < size; ++i)
sccstack[first+i].hash = hash_tree (cache, sccstack[first+i].t);
if (size == 1)
return sccstack[first].hash;
/* Sort the SCC of type, hash pairs so that when we mix in
all members of the SCC the hash value becomes independent on
the order we visited the SCC. Disregard hashes equal to
the hash of the tree we mix into because we cannot guarantee
a stable sort for those across different TUs. */
qsort (&sccstack[first], size, sizeof (scc_entry), scc_entry_compare);
which means returning 0 from the qsort compare function for hash
collisions. In theory the qsort implementation can randomly permute
stuff here leading to comparison fails.
I'm checking if breaking the tie via the DFS number fixes the miscompare
I saw.
Note that I assumed that "sane" implementations would behave consistently
here, but of course with address-space randomization and friends and an
implementation that breaks tie itself via addresses would break.
(I'd choose a simpler tie breaker - first argument to compare is less
than second arg to compare).
Well. Not sure what glibc msort does here.
That said, the smallest object I observe differences is build/genconfig.o
which has differences in the size(!) of the LTO_section_decls section
and differences already in the decl-state refs part.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (10 preceding siblings ...)
2014-08-12 9:20 ` rguenth at gcc dot gnu.org
@ 2014-08-12 10:52 ` venkataramanan.kumar at amd dot com
2014-08-12 11:07 ` sven.c.dack at virginmedia dot com
` (46 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-12 10:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #14 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
(In reply to Sven C. Dack from comment #6)
> It seems the problem is caused by the use of the jobserver. Changing
> bootstrap-lto.mk from:
>
> ...
> STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
> STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
> ...
>
> to:
>
> ...
> STAGE2_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1
> -ffat-lto-objects
> STAGE3_CFLAGS += -flto=1 -flto-partition=none -frandom-seed=1
> -ffat-lto-objects
> ...
>
> Results in a success without using an additional compare script:
>
> ...
> Comparing stages 2 and 3
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> Comparison successful.
> ...
I tried addding to stage2/3 the flags "-flto=1 -flto-partition=none" instead of
jobserver in bootstrap-lto.mk and spawned bootstrap LTO build in one amd64
machine. But still getting compare errors with GCC 4.9 branch. The HEAD is at
revision 213070.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (11 preceding siblings ...)
2014-08-12 10:52 ` venkataramanan.kumar at amd dot com
@ 2014-08-12 11:07 ` sven.c.dack at virginmedia dot com
2014-08-12 12:51 ` rguenth at gcc dot gnu.org
` (45 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-12 11:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #15 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
(In reply to Venkataramanan from comment #14)
> ...
> I tried addding to stage2/3 the flags "-flto=1 -flto-partition=none" instead
> of jobserver in bootstrap-lto.mk and spawned bootstrap LTO build in one
> amd64 machine. But still getting compare errors with GCC 4.9 branch. The
> HEAD is at revision 213070.
I have noticed a typo in one of my build scripts later this morning and am now
trying to verify the result. It is still not done yet. If it is indeed wrong
then I am going to take out the second patch.
I am also trying to use a "1to1" partition together with -flto=jobserver and
want to see if this makes a difference. This, too, is not done yet.
On a different note, I have managed to build a working compiler yesterday using
my compare-disassembly script with:
--with-build-config=bootstrap-lto
--with-boot-ldflags=-fuse-linker-plugin
I am still in the process of verifying it and running tests to see if I run
into any problems with it, but so far am I excited to have gotten this far.
gmp, mpfr and mpc have all been compiled with LTO enabled and have run their
testsuits without an error. I have tried pushing it further with "-fipa-pta
-fuse-liner-plugin", but ran out of memory (>16GB).
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails,
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (12 preceding siblings ...)
2014-08-12 11:07 ` sven.c.dack at virginmedia dot com
@ 2014-08-12 12:51 ` rguenth at gcc dot gnu.org
2014-08-13 8:06 ` [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails sven.c.dack at virginmedia dot com
` (44 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-12 12:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> ---
Ok, so what happens is that for build/genconfig.o we in one case write
a STRING_CST with a const char[7] with itself as main-variant and in
the other case with char[7] as main-variant. The STRING_CST is
written from ipa_write_jump_function
4237 case IPA_JF_CONST:
4238 gcc_assert (
4239 EXPR_LOCATION (jump_func->value.constant.value) ==
UNKNOWN_LOCATION);
4240 stream_write_tree (ob, jump_func->value.constant.value, true);
4241 break;
as &"#endif"[0]
Its type main variant is built in c-family/c-common.c:1021 and the literal
itself in builtins.c:13383.
And we indeed get differences in inline_param2 (min size), otherwise no
visible differences anywhere in dumps.
Not sure how that can explain the type difference for the jump function
though...
Again, this is build/genconfig.o as compiled by stage1 cc1plus vs. stage2
cc1plus (so faster to reproduce / bisect).
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (13 preceding siblings ...)
2014-08-12 12:51 ` rguenth at gcc dot gnu.org
@ 2014-08-13 8:06 ` sven.c.dack at virginmedia dot com
2014-08-13 8:18 ` sven.c.dack at virginmedia dot com
` (43 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-13 8:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack <sven.c.dack at virginmedia dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|--with-build-config=bootstr |--with-build-config=bootstr
|ap-lto fails, |ap-lto fails
--- Comment #17 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
I have tested several command line options to see if these change anything, but
they all give the exact same comparison failures (same files and in the same
ordering):
-flto=jobserver -flto-partition=1to1
-flto=jobserver -flto-partition=none
-flto=1 -flto-partition=none
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (14 preceding siblings ...)
2014-08-13 8:06 ` [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails sven.c.dack at virginmedia dot com
@ 2014-08-13 8:18 ` sven.c.dack at virginmedia dot com
2014-08-13 9:25 ` rguenth at gcc dot gnu.org
` (42 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-13 8:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Sven C. Dack <sven.c.dack at virginmedia dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #33299|0 |1
is obsolete| |
--- Comment #18 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
Created attachment 33310
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33310&action=edit
Work-around: changes the way bootstrap-lto.mk compares object files
The patch changes the way bootstrap-lto.mk compares object files during the
comparison of stage 2 and 3 by only comparing the disassembled code. It works
around situations where a possibly correct compiler can be produced while it
still has differences in their object files.
This also reverts the last patch, which was based on a false positive.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (15 preceding siblings ...)
2014-08-13 8:18 ` sven.c.dack at virginmedia dot com
@ 2014-08-13 9:25 ` rguenth at gcc dot gnu.org
2014-08-13 9:57 ` rguenth at gcc dot gnu.org
` (41 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-13 9:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that the differences can be reproduced even with non-LTO cc1/cc1plus.
Thus,
do a regular bootstrap --without-build-config then re-build stage2
build/genconfig.o with -flto (using
the stage1 compiler) and stage3 build/genconfig.o with -flto (using the stage2
compiler) and observe the exact same differences.
Without IPA-CP the difference in genconfig.o just jumps to a later place.
I'm quite sure the difference in the string literal type also occurs
without -flto but I don't see an easy way to verify that(?)
Maybe this is all spurious with host compiler capabilities leaking into
the IL in some way (not affecting code generation by luck).
- I'm testing if trunk is really not affected (with
--enable-checking=release).
- We need to track down that min_size issue sawn (but it looks unrelated)
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (16 preceding siblings ...)
2014-08-13 9:25 ` rguenth at gcc dot gnu.org
@ 2014-08-13 9:57 ` rguenth at gcc dot gnu.org
2014-08-13 10:00 ` venkataramanan.kumar at amd dot com
` (40 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-13 9:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #19)
> Note that the differences can be reproduced even with non-LTO cc1/cc1plus.
> Thus,
> do a regular bootstrap --without-build-config then re-build stage2
> build/genconfig.o with -flto (using
> the stage1 compiler) and stage3 build/genconfig.o with -flto (using the
> stage2
> compiler) and observe the exact same differences.
>
> Without IPA-CP the difference in genconfig.o just jumps to a later place.
> I'm quite sure the difference in the string literal type also occurs
> without -flto but I don't see an easy way to verify that(?)
>
> Maybe this is all spurious with host compiler capabilities leaking into
> the IL in some way (not affecting code generation by luck).
>
> - I'm testing if trunk is really not affected (with
> --enable-checking=release).
It indeed works. Back to the question what fixed it ...
> - We need to track down that min_size issue sawn (but it looks unrelated)
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (17 preceding siblings ...)
2014-08-13 9:57 ` rguenth at gcc dot gnu.org
@ 2014-08-13 10:00 ` venkataramanan.kumar at amd dot com
2014-08-13 11:05 ` rguenth at gcc dot gnu.org
` (39 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-13 10:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #21 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
I randomly tried some revisions and last one that passed was r209650 on
2014-04-22. I am still continuing to go down and see some more revision.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (18 preceding siblings ...)
2014-08-13 10:00 ` venkataramanan.kumar at amd dot com
@ 2014-08-13 11:05 ` rguenth at gcc dot gnu.org
2014-08-13 11:12 ` rguenth at gcc dot gnu.org
` (38 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-13 11:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
So if I instrument build_string_literal with
Index: builtins.c
===================================================================
--- builtins.c (revision 213814)
+++ builtins.c (working copy)
@@ -59,6 +59,8 @@ along with GCC; see the file COPYING3.
#include "builtins.h"
#include "ubsan.h"
#include "cilk.h"
+#include "dumpfile.h"
+#include "tree-pretty-print.h"
static tree do_mpc_arg1 (tree, tree, int (*)(mpc_ptr, mpc_srcptr, mpc_rnd_t));
@@ -4695,6 +4697,15 @@ build_string_literal (int len, const cha
elem = build_type_variant (char_type_node, 1, 0);
index = build_index_type (size_int (len - 1));
type = build_array_type (elem, index);
+ fprintf (stderr, "%s <%p> ", str, (void *)type);
+ print_generic_expr (stderr, type, TDF_SLIM);
+ if (TYPE_MAIN_VARIANT (type) == type)
+ ;
+ else
+ {
+ fprintf (stderr, " <%p> ", (void *)TYPE_MAIN_VARIANT (type));
+ print_generic_expr (stderr, TYPE_MAIN_VARIANT (type), TDF_SLIM);
+ }
+ fprintf (stderr, "\n");
TREE_TYPE (t) = type;
TREE_CONSTANT (t) = 1;
TREE_READONLY (t) = 1;
then I get for building non-LTO stage2 build/genconfig.o
#ifndef MAX_INSNS_PER_SPLIT
<0x7ffff5af4e70> const char[28]
#endif
<0x7ffff5af6000> const char[7]
#define HAVE_cc0 1
<0x7ffff5af6150> const char[19]
#define CC0_P(X) ((X) == cc0_rtx)
<0x7ffff5af62a0> const char[34]
#define CC0_P(X) ((X) ? 0 : 0)
<0x7ffff5aef540> const char[31] <0x7ffff5aef498> char[31]
#define HAVE_conditional_move 1
<0x7ffff5aefe70> const char[32] <0x7ffff5de6d20> char[32]
#define HAVE_conditional_execution 1
<0x7ffff5af6690> const char[37]
#define HAVE_lo_sum 1
<0x7ffff5af67e0> const char[22]
#define HAVE_peephole 1
<0x7ffff5af6930> const char[24]
#define HAVE_peephole2 1
<0x7ffff5af45e8> const char[25] <0x7ffff5af4540> char[25]
and for stage3:
#ifndef MAX_INSNS_PER_SPLIT
<0x7ffff5db9150> const char[28]
#endif
<0x7ffff601bc78> const char[7] <0x7ffff601bbd0> char[7]
#define HAVE_cc0 1
<0x7ffff5db93f0> const char[19]
#define CC0_P(X) ((X) == cc0_rtx)
<0x7ffff5db9540> const char[34]
#define CC0_P(X) ((X) ? 0 : 0)
<0x7ffff5db17e0> const char[31] <0x7ffff5db1738> char[31]
#define HAVE_conditional_move 1
<0x7ffff5db4150> const char[32] <0x7ffff6017888> char[32]
#define HAVE_conditional_execution 1
<0x7ffff5db9930> const char[37]
#define HAVE_lo_sum 1
<0x7ffff5db9a80> const char[22]
#define HAVE_peephole 1
<0x7ffff5db9bd0> const char[24]
#define HAVE_peephole2 1
<0x7ffff5db5888> const char[25] <0x7ffff5db57e0> char[25]
so whether the #endif literal has a TYPE_MAIN_VARIANT or not changes.
Which means in one case somebody builds that very same array type
earlier.
Instrumenting build_array_type I see that stage3 doesn't build some
types stage2 builds. Weird.
Ah. Well - type_hash_table is marked as GC-able thus when using the
stage1 compiler we run with --param ggc-min-expand=30 --param
ggc-min-heapsize=4096 but when using the stage2 compiler we use
--param ggc-min-expand=100 --param ggc-min-heapsize=131072.
using the same --param settings for stage2 fixes this difference
(but not fully the miscompare in the LTO object).
But this _is_ an issue for reproducability of LTO IL (and types
in general).
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (19 preceding siblings ...)
2014-08-13 11:05 ` rguenth at gcc dot gnu.org
@ 2014-08-13 11:12 ` rguenth at gcc dot gnu.org
2014-08-13 11:21 ` rguenth at gcc dot gnu.org
` (37 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-13 11:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #22)
> So if I instrument build_string_literal with
>
> Index: builtins.c
> ===================================================================
> --- builtins.c (revision 213814)
> +++ builtins.c (working copy)
> @@ -59,6 +59,8 @@ along with GCC; see the file COPYING3.
> #include "builtins.h"
> #include "ubsan.h"
> #include "cilk.h"
> +#include "dumpfile.h"
> +#include "tree-pretty-print.h"
>
>
> static tree do_mpc_arg1 (tree, tree, int (*)(mpc_ptr, mpc_srcptr,
> mpc_rnd_t));
> @@ -4695,6 +4697,15 @@ build_string_literal (int len, const cha
> elem = build_type_variant (char_type_node, 1, 0);
> index = build_index_type (size_int (len - 1));
> type = build_array_type (elem, index);
> + fprintf (stderr, "%s <%p> ", str, (void *)type);
> + print_generic_expr (stderr, type, TDF_SLIM);
> + if (TYPE_MAIN_VARIANT (type) == type)
> + ;
> + else
> + {
> + fprintf (stderr, " <%p> ", (void *)TYPE_MAIN_VARIANT (type));
> + print_generic_expr (stderr, TYPE_MAIN_VARIANT (type), TDF_SLIM);
> + }
> + fprintf (stderr, "\n");
> TREE_TYPE (t) = type;
> TREE_CONSTANT (t) = 1;
> TREE_READONLY (t) = 1;
>
>
> then I get for building non-LTO stage2 build/genconfig.o
>
> #ifndef MAX_INSNS_PER_SPLIT
> <0x7ffff5af4e70> const char[28]
> #endif
> <0x7ffff5af6000> const char[7]
> #define HAVE_cc0 1
> <0x7ffff5af6150> const char[19]
> #define CC0_P(X) ((X) == cc0_rtx)
> <0x7ffff5af62a0> const char[34]
> #define CC0_P(X) ((X) ? 0 : 0)
> <0x7ffff5aef540> const char[31] <0x7ffff5aef498> char[31]
> #define HAVE_conditional_move 1
> <0x7ffff5aefe70> const char[32] <0x7ffff5de6d20> char[32]
> #define HAVE_conditional_execution 1
> <0x7ffff5af6690> const char[37]
> #define HAVE_lo_sum 1
> <0x7ffff5af67e0> const char[22]
> #define HAVE_peephole 1
> <0x7ffff5af6930> const char[24]
> #define HAVE_peephole2 1
> <0x7ffff5af45e8> const char[25] <0x7ffff5af4540> char[25]
>
> and for stage3:
>
> #ifndef MAX_INSNS_PER_SPLIT
> <0x7ffff5db9150> const char[28]
> #endif
> <0x7ffff601bc78> const char[7] <0x7ffff601bbd0> char[7]
> #define HAVE_cc0 1
> <0x7ffff5db93f0> const char[19]
> #define CC0_P(X) ((X) == cc0_rtx)
> <0x7ffff5db9540> const char[34]
> #define CC0_P(X) ((X) ? 0 : 0)
> <0x7ffff5db17e0> const char[31] <0x7ffff5db1738> char[31]
> #define HAVE_conditional_move 1
> <0x7ffff5db4150> const char[32] <0x7ffff6017888> char[32]
> #define HAVE_conditional_execution 1
> <0x7ffff5db9930> const char[37]
> #define HAVE_lo_sum 1
> <0x7ffff5db9a80> const char[22]
> #define HAVE_peephole 1
> <0x7ffff5db9bd0> const char[24]
> #define HAVE_peephole2 1
> <0x7ffff5db5888> const char[25] <0x7ffff5db57e0> char[25]
>
> so whether the #endif literal has a TYPE_MAIN_VARIANT or not changes.
> Which means in one case somebody builds that very same array type
> earlier.
>
> Instrumenting build_array_type I see that stage3 doesn't build some
> types stage2 builds. Weird.
>
> Ah. Well - type_hash_table is marked as GC-able thus when using the
> stage1 compiler we run with --param ggc-min-expand=30 --param
> ggc-min-heapsize=4096 but when using the stage2 compiler we use
> --param ggc-min-expand=100 --param ggc-min-heapsize=131072.
>
> using the same --param settings for stage2 fixes this difference
> (but not fully the miscompare in the LTO object).
Now a difference is only in .shstrtab (huh?). Ah, from the differences
in section name due to hashing them (too lame reproducer).
So making GC behave the same for the stage1 compiler and the stage2
compiler fixes things.
trying
Index: config/bootstrap-lto.mk
===================================================================
--- config/bootstrap-lto.mk (revision 213899)
+++ config/bootstrap-lto.mk (working copy)
@@ -2,6 +2,6 @@
# FIXME: Our build system is not yet able to use gcc-ar wrapper, so we need
# to go with -ffat-lto-objects.
-STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
-STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
+STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param
ggc-min-expand=100 --param ggc-min-heapsize=131072
+STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param
ggc-min-expand=100 --param ggc-min-heapsize=131072
STAGEprofile_CFLAGS += -fno-lto
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (20 preceding siblings ...)
2014-08-13 11:12 ` rguenth at gcc dot gnu.org
@ 2014-08-13 11:21 ` rguenth at gcc dot gnu.org
2014-08-13 12:34 ` rguenth at gcc dot gnu.org
` (36 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-13 11:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
Or "real" fix for the type_hash_canon issue (untested)
Index: gcc/tree.c
===================================================================
--- gcc/tree.c (revision 213814)
+++ gcc/tree.c (working copy)
@@ -6593,7 +6593,9 @@ type_hash_eq (const void *va, const void
|| !attribute_list_equal (TYPE_ATTRIBUTES (a->type),
TYPE_ATTRIBUTES (b->type))
|| (TREE_CODE (a->type) != COMPLEX_TYPE
- && TYPE_NAME (a->type) != TYPE_NAME (b->type)))
+ && TYPE_NAME (a->type) != TYPE_NAME (b->type))
+ || ((TYPE_MAIN_VARIANT (a->type) == TYPE_MAIN_VARIANT (a->type))
+ != (TYPE_MAIN_VARIANT (b->type) == TYPE_MAIN_VARIANT (b->type))))
return 0;
/* Be careful about comparing arrays before and after the element type
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (21 preceding siblings ...)
2014-08-13 11:21 ` rguenth at gcc dot gnu.org
@ 2014-08-13 12:34 ` rguenth at gcc dot gnu.org
2014-08-13 13:51 ` rguenth at gcc dot gnu.org
` (35 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-13 12:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org
--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
Patch in testing.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (22 preceding siblings ...)
2014-08-13 12:34 ` rguenth at gcc dot gnu.org
@ 2014-08-13 13:51 ` rguenth at gcc dot gnu.org
2014-08-13 14:02 ` sven.c.dack at virginmedia dot com
` (34 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-13 13:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jason at gcc dot gnu.org
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #24)
> Or "real" fix for the type_hash_canon issue (untested)
>
> Index: gcc/tree.c
> ===================================================================
> --- gcc/tree.c (revision 213814)
> +++ gcc/tree.c (working copy)
> @@ -6593,7 +6593,9 @@ type_hash_eq (const void *va, const void
> || !attribute_list_equal (TYPE_ATTRIBUTES (a->type),
> TYPE_ATTRIBUTES (b->type))
> || (TREE_CODE (a->type) != COMPLEX_TYPE
> - && TYPE_NAME (a->type) != TYPE_NAME (b->type)))
> + && TYPE_NAME (a->type) != TYPE_NAME (b->type))
> + || ((TYPE_MAIN_VARIANT (a->type) == TYPE_MAIN_VARIANT (a->type))
> + != (TYPE_MAIN_VARIANT (b->type) == TYPE_MAIN_VARIANT (b->type))))
> return 0;
>
> /* Be careful about comparing arrays before and after the element type
Hmpf, that doesn't fix it. But the following makes us ICE:
Index: tree.c
===================================================================
--- tree.c (revision 213814)
+++ tree.c (working copy)
@@ -6759,6 +6761,7 @@ type_hash_canon (unsigned int hashcode,
t1 = type_hash_lookup (hashcode, type);
if (t1 != 0)
{
+ gcc_assert (TYPE_MAIN_VARIANT (t1) == t1);
if (GATHER_STATISTICS)
{
tree_code_counts[(int) TREE_CODE (type)]--;
which means somebody mangles TYPE_MAIN_VARIANT of a type already in
the type hash table.
build_cplus_array_type is it:
/* We want TYPE_MAIN_VARIANT of an array to strip cv-quals from the
element type as well, so fix it up if needed. */
if (elt_type != TYPE_MAIN_VARIANT (elt_type))
{
tree m = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
index_type);
...
TYPE_MAIN_VARIANT (t) = m;
Jason? Something like
Index: cp/tree.c
===================================================================
--- cp/tree.c (revision 213814)
+++ cp/tree.c (working copy)
@@ -824,7 +824,11 @@ build_cplus_array_type (tree elt_type, t
build_cplus_array_type
(TYPE_CANONICAL (elt_type),
index_type ? TYPE_CANONICAL (index_type) : index_type);
- t = build_array_type (elt_type, index_type);
+ if (elt_type != TYPE_MAIN_VARIANT (elt_type))
+ t = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
+ index_type);
+ else
+ t = build_array_type (elt_type, index_type);
}
/* Push these needs up so that initialization takes place
@@ -840,37 +844,19 @@ build_cplus_array_type (tree elt_type, t
element type as well, so fix it up if needed. */
if (elt_type != TYPE_MAIN_VARIANT (elt_type))
{
- tree m = build_cplus_array_type (TYPE_MAIN_VARIANT (elt_type),
- index_type);
-
- if (TYPE_MAIN_VARIANT (t) != m)
+ /* ??? We didn't even try to re-use existing types?
+ ??? Ah, we did via the type_hash_canon that this breaks. */
+ tree t1;
+ for (t1 = TYPE_MAIN_VARIANT (t); t1; t1 = TYPE_NEXT_VARIANT (t1))
+ if (TREE_TYPE (t1) == elt_type)
+ {
+ t = t1;
+ break;
+ }
+ if (!t1)
{
- if (COMPLETE_TYPE_P (TREE_TYPE (t)) && !COMPLETE_TYPE_P (m))
- {
- /* m was built before the element type was complete, so we
- also need to copy the layout info from t. We might
- end up doing this multiple times if t is an array of
- unknown bound. */
- tree size = TYPE_SIZE (t);
- tree size_unit = TYPE_SIZE_UNIT (t);
- unsigned int align = TYPE_ALIGN (t);
- unsigned int user_align = TYPE_USER_ALIGN (t);
- enum machine_mode mode = TYPE_MODE (t);
- for (tree var = m; var; var = TYPE_NEXT_VARIANT (var))
- {
- TYPE_SIZE (var) = size;
- TYPE_SIZE_UNIT (var) = size_unit;
- TYPE_ALIGN (var) = align;
- TYPE_USER_ALIGN (var) = user_align;
- SET_TYPE_MODE (var, mode);
- TYPE_NEEDS_CONSTRUCTING (var) = needs_ctor;
- TYPE_HAS_NONTRIVIAL_DESTRUCTOR (var) = needs_dtor;
- }
- }
-
- TYPE_MAIN_VARIANT (t) = m;
- TYPE_NEXT_VARIANT (t) = TYPE_NEXT_VARIANT (m);
- TYPE_NEXT_VARIANT (m) = t;
+ t = build_variant_type_copy (t);
+ TREE_TYPE (t) = elt_type;
}
}
fixes that - but eventually breaks whatever needed that odd type completion,
which we also can't allow on types that are recorded in the type_hash_canon
hashtable. Not sure how that code can trigger when we build m right
before using elt_type which is now either not complete or complete (and so is
t).
The above fixes the LTO miscompares. Let's see if it survives LTO bootstrap.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (23 preceding siblings ...)
2014-08-13 13:51 ` rguenth at gcc dot gnu.org
@ 2014-08-13 14:02 ` sven.c.dack at virginmedia dot com
2014-08-13 15:09 ` venkataramanan.kumar at amd dot com
` (33 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-13 14:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #27 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
(In reply to Richard Biener from comment #24)
> Or "real" fix for the type_hash_canon issue (untested)
>
> Index: gcc/tree.c
> ===================================================================
> --- gcc/tree.c (revision 213814)
> +++ gcc/tree.c (working copy)
> @@ -6593,7 +6593,9 @@ type_hash_eq (const void *va, const void
> || !attribute_list_equal (TYPE_ATTRIBUTES (a->type),
> TYPE_ATTRIBUTES (b->type))
> || (TREE_CODE (a->type) != COMPLEX_TYPE
> - && TYPE_NAME (a->type) != TYPE_NAME (b->type)))
> + && TYPE_NAME (a->type) != TYPE_NAME (b->type))
> + || ((TYPE_MAIN_VARIANT (a->type) == TYPE_MAIN_VARIANT (a->type))
> + != (TYPE_MAIN_VARIANT (b->type) == TYPE_MAIN_VARIANT (b->type))))
> return 0;
>
> /* Be careful about comparing arrays before and after the element type
This looks wrong. It looks like you are doing "... || ((true) != (true))".
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (24 preceding siblings ...)
2014-08-13 14:02 ` sven.c.dack at virginmedia dot com
@ 2014-08-13 15:09 ` venkataramanan.kumar at amd dot com
2014-08-13 19:43 ` venkataramanan.kumar at amd dot com
` (32 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-13 15:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #28 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
Richard,
I am still not able to understand why this problem is not seen in trunk.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (25 preceding siblings ...)
2014-08-13 15:09 ` venkataramanan.kumar at amd dot com
@ 2014-08-13 19:43 ` venkataramanan.kumar at amd dot com
2014-08-14 7:26 ` venkataramanan.kumar at amd dot com
` (31 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-13 19:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #29 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
Hi Richard,
I tried the patch you posted last on GCC patches, on top of GCC 4.9 on Aarch64.
https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01324.html
I am still getting same number of compare errors.
Now I will try adding --param ggc-min-expand=100 --param
ggc-min-heapsize=131072 to stage2 and stage3 flags.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (26 preceding siblings ...)
2014-08-13 19:43 ` venkataramanan.kumar at amd dot com
@ 2014-08-14 7:26 ` venkataramanan.kumar at amd dot com
2014-08-14 8:45 ` rguenth at gcc dot gnu.org
` (30 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-14 7:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #31 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
(In reply to Venkataramanan from comment #30)
> (In reply to Venkataramanan from comment #29)
> > Hi Richard,
> >
> > I tried the patch you posted last on GCC patches, on top of GCC 4.9 on
> > Aarch64.
> > https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01324.html
> >
> > I am still getting same number of compare errors.
> >
> > Now I will try adding --param ggc-min-expand=100 --param
> > ggc-min-heapsize=131072 to stage2 and stage3 flags.
>
> I am getting more compare errors in Aarch64 machine in this case.
> aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi.o differs
> aarch64-unknown-linux-gnu/libgcc/_fixxfdi_s.o differs
> aarch64-unknown-linux-gnu/libgcc/_fixunsxfsi_s.o differs
> aarch64-unknown-linux-gnu/libgcc/_ctors_s.o differs
> aarch64-unknown-linux-gnu/libgcc/_floatdixf.o differs
> aarch64-unknown-linux-gnu/libgcc/_popcount_tab_s.o differs
> aarch64-unknown-linux-gnu/libgcc/_powixf2.o differs
> aarch64-unknown-linux-gnu/libgcc/unwind-sjlj.o differs
> aarch64-unknown-linux-gnu/libgcc/unwind-sjlj_s.o differs
> aarch64-unknown-linux-gnu/libgcc/crtendS.o differs
> gcc/sdbout.o differs
> gcc/c/c-lang.o differs
> gcc/graphite-poly.o differs
> gcc/graphite-dependences.o differs
> gcc/crtend.o differs
> gcc/vmsdbgout.o differs
> gcc/hw-doloop.o differs
> gcc/graphite-optimize-isl.o differs
> gcc/version.o differs
> gcc/target-globals.o differs
> gcc/graphite-interchange.o differs
> gcc/collect2-aix.o differs
> gcc/graphite-scop-detection.o differs
> gcc/loop-doloop.o differs
> gcc/graphite-blocking.o differs
> gcc/graphite-clast-to-gimple.o differs
> gcc/build/min-insn-modes.o differs
> gcc/build/version.o differs
> gcc/graphite-sese-to-poly.o differs
> gcc/insn-peep.o differs
> gcc/insn-enums.o differs
> gcc/xcoffout.o differs
> gcc/crtendS.o differs
> libbacktrace/atomic.o differs
> libiberty/pic/safe-ctype.o differs
> libiberty/pic/getopt.o differs
> libiberty/pic/obstack.o differs
> libiberty/pic/fnmatch.o differs
> libiberty/pic/getopt1.o differs
> libiberty/safe-ctype.o differs
> libiberty/getopt.o differs
> libiberty/obstack.o differs
> libiberty/fnmatch.o differs
> libiberty/getopt1.o differs
>
>
> I will try to test the patch on x86_64 machine now.
Richard,
I thought I used existing build directory for the patch test.
So did another build with gcc 4.9 + garbage collector tuning flags for stage2/3
on Aarch64.
(Snip)
STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param
ggc-min-expand=100 --param ggc-min-heapsize=131072
STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param
ggc-min-expand=100 --param ggc-min-heapsize=131072
(Snip)
Bootstrap passes cleanly.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (27 preceding siblings ...)
2014-08-14 7:26 ` venkataramanan.kumar at amd dot com
@ 2014-08-14 8:45 ` rguenth at gcc dot gnu.org
2014-08-14 10:30 ` rguenth at gcc dot gnu.org
` (29 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-14 8:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> ---
Yeah, to summarize:
- Using --param ggc-min-expand=100 --param ggc-min-heapsize=131072 fixes
LTO bootstrap (I tested x86_64 on the 4.9 branch)
- Using the patch from comment #26 doesn't fix LTO bootstrap but makes
build/genconfig.o no longer to miscompare
Thus we seem to have a multitude of GC-related "IL" differences. Ugh.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (28 preceding siblings ...)
2014-08-14 8:45 ` rguenth at gcc dot gnu.org
@ 2014-08-14 10:30 ` rguenth at gcc dot gnu.org
2014-08-14 12:36 ` venkataramanan.kumar at amd dot com
` (28 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-08-14 10:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #33 from Richard Biener <rguenth at gcc dot gnu.org> ---
Another difference - graphite-interchange.o - is due to streaming the indexed
decl for fprintf differently. stage2 streams
[1968] = tree_list <0x7ffff6703ac8>
[1969] = identifier_node <0x7ffff66ddf20>
[1970] = identifier_node <0x7ffff6706210>
[1971] = tree_list <0x7ffff6703af0>
[1972] = tree_list <0x7ffff6703c30>
[1973] = tree_list <0x7ffff6707488>
[1974] = tree_list <0x7ffff67861b8>
[1975] = tree_list <0x7ffff67861e0>
[1976] = tree_list <0x7ffff4dddaf0>
[1977] = tree_list <0x7ffff4dddac8>
[1978] = function_type <0x7ffff4de05e8>
[1979] = identifier_node <0x7ffff6781840>
[1980] = function_decl <0x7ffff6784d00>
while stage3
[1968] = tree_list <0x7ffff6703ac8>
[1969] = identifier_node <0x7ffff66ddf20>
[1970] = identifier_node <0x7ffff6706210>
[1971] = tree_list <0x7ffff6703af0>
[1972] = tree_list <0x7ffff6703c30>
[1973] = tree_list <0x7ffff6707488>
[1974] = tree_list <0x7ffff67861b8>
[1975] = tree_list <0x7ffff67861e0>
[1976] = function_type <0x7ffff4de05e8>
[1977] = identifier_node <0x7ffff6781840>
[1978] = function_decl <0x7ffff6784d00>
the tree_list differences come from stage2 streaming TYPE_ARG_TYPEs while
stage3 producing a reference to previously written ones (streamed for
__gmp_fprintf). Note that stage3 re-uses (aka shares) TYPE_ARG_TYPEs
for fprintf and __gmp_fprintf while stage2 does not (the FUNCTION_TYPE
itself is not shared).
I don't even see where we would share TYPE_ARG_TYPEs but not the FUNCTION_TYPE
itself... maybe it happens when parsing first builds a function type
without attributes and then later appends attributes to them?
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (29 preceding siblings ...)
2014-08-14 10:30 ` rguenth at gcc dot gnu.org
@ 2014-08-14 12:36 ` venkataramanan.kumar at amd dot com
2014-08-14 17:48 ` sven.c.dack at virginmedia dot com
` (27 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-14 12:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #34 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
Richard, What I understand is that instead of using tune flags for garbage
collection, need to try and fix the object code differences?
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (30 preceding siblings ...)
2014-08-14 12:36 ` venkataramanan.kumar at amd dot com
@ 2014-08-14 17:48 ` sven.c.dack at virginmedia dot com
2014-08-14 22:49 ` sven.c.dack at virginmedia dot com
` (26 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-14 17:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #37 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
> ...
> trying
>
> Index: config/bootstrap-lto.mk
> ===================================================================
> --- config/bootstrap-lto.mk (revision 213899)
> +++ config/bootstrap-lto.mk (working copy)
> @@ -2,6 +2,6 @@
> # FIXME: Our build system is not yet able to use gcc-ar wrapper, so we need
> # to go with -ffat-lto-objects.
>
> -STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
> -STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects
> +STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param
> ggc-min-expand=100 --param ggc-min-heapsize=131072
> +STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects --param
> ggc-min-expand=100 --param ggc-min-heapsize=131072
> STAGEprofile_CFLAGS += -fno-lto
It works for me, too. It has compiled 4.9.2-20140806
--with-build-config=bootstrap-lto and --with-boot-ldflags="-fuse-linker-plugin"
successfully. It is now running the testsuite.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (31 preceding siblings ...)
2014-08-14 17:48 ` sven.c.dack at virginmedia dot com
@ 2014-08-14 22:49 ` sven.c.dack at virginmedia dot com
2014-08-15 5:38 ` sven.c.dack at virginmedia dot com
` (25 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-14 22:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #38 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
The testsuite run looks good:
# of expected passes 105750
# of unexpected failures 3
# of expected failures 252
# of expected passes 87886
# of unexpected failures 2
# of unexpected successes 2
# of expected failures 443
# of expected passes 9246
# of unexpected failures 6
# of expected failures 41
# of expected passes 689
# of expected passes 26
# of expected failures 3
# of expected passes 54
Only 13 unexpected results, but these might be in there with or without LTO. I
have not crossed checked it against a standard bootstrap yet.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (32 preceding siblings ...)
2014-08-14 22:49 ` sven.c.dack at virginmedia dot com
@ 2014-08-15 5:38 ` sven.c.dack at virginmedia dot com
2014-08-15 10:22 ` sven.c.dack at virginmedia dot com
` (24 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-15 5:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #39 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
(In reply to Sven C. Dack from comment #38)
> The testsuite run looks good:
>
> # of expected passes 105750
> # of unexpected failures 3
> # of expected failures 252
> # of expected passes 87886
> # of unexpected failures 2
> # of unexpected successes 2
> # of expected failures 443
> # of expected passes 9246
> # of unexpected failures 6
> # of expected failures 41
> # of expected passes 689
> # of expected passes 26
> # of expected failures 3
> # of expected passes 54
>
> Only 13 unexpected results, but these might be in there with or without LTO.
> I have not crossed checked it against a standard bootstrap yet.
The testsuite gives identical numbers of expected and unexpected results for a
non-LTO build with 4.9.2-20140806.
I am going to sit back now. Let me know if there is something I can do for you.
Sven
$ uname -a
Linux debian-linux 3.14.17-sven #1 SMP Thu Aug 14 10:54:21 BST 2014 x86_64
GNU/Linux
$ gcc --version
gcc (GCC) 4.9.2 20140806 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>From gcc-bugs-return-458526-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 15 05:50:40 2014
Return-Path: <gcc-bugs-return-458526-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7990 invoked by alias); 15 Aug 2014 05:50:39 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7946 invoked by uid 55); 15 Aug 2014 05:50:33 -0000
From: "amker at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/62032] FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none
Date: Fri, 15 Aug 2014 05:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: lto
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: amker at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-62032-4-bc3ByqFuN3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62032-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62032-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg01023.txt.bz2
Content-length: 493
https://gcc.gnu.org/bugzilla/show_bug.cgi?idb032
--- Comment #6 from amker at gcc dot gnu.org ---
Author: amker
Date: Fri Aug 15 05:49:56 2014
New Revision: 214000
URL: https://gcc.gnu.org/viewcvs?rev!4000&root=gcc&view=rev
Log:
Backport from mainline
2014-08-08 Bin Cheng <bin.cheng@arm.com>
PR lto/62032
* lto-lang.c (lto_init): Switch mis-matched arguments.
Modified:
branches/gcc-4_9-branch/gcc/lto/ChangeLog
branches/gcc-4_9-branch/gcc/lto/lto-lang.c
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (33 preceding siblings ...)
2014-08-15 5:38 ` sven.c.dack at virginmedia dot com
@ 2014-08-15 10:22 ` sven.c.dack at virginmedia dot com
2014-08-15 10:26 ` rguenther at suse dot de
` (23 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-15 10:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #40 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
I ran benchmarks and got some unusual results. Or perhaps it is a regression?
I have created 4 versions of gcc and used these to timed the time it takes to
compile a linux kernel. The configuration of the 4 gcc's are:
CFLAGS='-pipe -O2 -march=native -fomit-frame-pointer -fno-builtin-memcmp'
default:
configure ...
make bootstrap
profiled:
configure ...
make profiledbootstrap
lto:
configure ... --with-build-config=bootstrap-lto
make bootstrap
lto-plugin:
configure ... --with-build-config=bootstrap-lto
--with-boot-ldflags="-fuse-linker-plugin"
make bootstrap
The results are the averages (and deviations) of 5 runs with each compiler:
avg stdev %
default: 282.86s 0.56s, 0.20% 100.00% (base)
profiled: 255.76s 0.72s, 0.28% +10.60%
lto: 282.80s 0.16s, 0.06% +0.02%
lto-plugin: 285.41s 0.49s, 0.17% -0.89%
The file sizes of the cc1's are:
default: 84920k
profiled: 90176k
lto: 71204k
lto-plugin: 60024k
So boot strapping with LTO does not make gcc faster, but only smaller and also
takes more time. It is almost as if I had used -Os (and not -O2).
With the linker plugin enabled does it actually link libgcc_s.so and
libstdc++.so dynamically to it, while for the other three it did not:
default cc1:
libmpc.so.3 => /home/sven/gcc-default/lib/libmpc.so.3
libmpfr.so.4 => /home/sven/gcc-default/lib/libmpfr.so.4
libgmp.so.10 => /home/sven/gcc-default/lib/libgmp.so.10
profiled cc1:
libmpc.so.3 => /home/sven/gcc-profiled/lib/libmpc.so.3
libmpfr.so.4 => /home/sven/gcc-profiled/lib/libmpfr.so.4
libgmp.so.10 => /home/sven/gcc-profiled/lib/libgmp.so.10
lto cc1:
libmpc.so.3 => /home/sven/gcc-lto/lib/libmpc.so.3
libmpfr.so.4 => /home/sven/gcc-lto/lib/libmpfr.so.4
libgmp.so.10 => /home/sven/gcc-lto/lib/libgmp.so.10
lto-plugin cc1:
libmpc.so.3 => /home/sven/gcc-lto-plugin/lib/libmpc.so.3
libmpfr.so.4 => /home/sven/gcc-lto-plugin/lib/libmpfr.so.4
libgmp.so.10 => /home/sven/gcc-lto-plugin/lib/libgmp.so.10
libstdc++.so.6 => /home/sven/gcc-lto-plugin/lib64/libstdc++.so.6
libgcc_s.so.1 => /home/sven/gcc-lto-plugin/lib64/libgcc_s.so.1
I will try doing the same but with statically linked compilers.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (34 preceding siblings ...)
2014-08-15 10:22 ` sven.c.dack at virginmedia dot com
@ 2014-08-15 10:26 ` rguenther at suse dot de
2014-08-15 10:44 ` trippels at gcc dot gnu.org
` (22 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenther at suse dot de @ 2014-08-15 10:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #41 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 15 Aug 2014, sven.c.dack at virginmedia dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> --- Comment #40 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
> I ran benchmarks and got some unusual results. Or perhaps it is a regression?
>
> I have created 4 versions of gcc and used these to timed the time it takes to
> compile a linux kernel. The configuration of the 4 gcc's are:
>
> CFLAGS='-pipe -O2 -march=native -fomit-frame-pointer -fno-builtin-memcmp'
>
> default:
> configure ...
> make bootstrap
>
> profiled:
> configure ...
> make profiledbootstrap
>
> lto:
> configure ... --with-build-config=bootstrap-lto
> make bootstrap
>
> lto-plugin:
> configure ... --with-build-config=bootstrap-lto
> --with-boot-ldflags="-fuse-linker-plugin"
> make bootstrap
>
> The results are the averages (and deviations) of 5 runs with each compiler:
>
> avg stdev %
> default: 282.86s 0.56s, 0.20% 100.00% (base)
> profiled: 255.76s 0.72s, 0.28% +10.60%
> lto: 282.80s 0.16s, 0.06% +0.02%
> lto-plugin: 285.41s 0.49s, 0.17% -0.89%
>
> The file sizes of the cc1's are:
>
> default: 84920k
> profiled: 90176k
> lto: 71204k
> lto-plugin: 60024k
>
> So boot strapping with LTO does not make gcc faster, but only smaller and also
> takes more time. It is almost as if I had used -Os (and not -O2).
Most interesting is bootstrap-lto and make profiledbootstrap.
> With the linker plugin enabled does it actually link libgcc_s.so and
> libstdc++.so dynamically to it, while for the other three it did not:
That looks odd. Btw, -fuse-linker-plugin should be the default
if you have recent enough binutils.
Richard
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (35 preceding siblings ...)
2014-08-15 10:26 ` rguenther at suse dot de
@ 2014-08-15 10:44 ` trippels at gcc dot gnu.org
2014-08-15 10:56 ` sven.c.dack at virginmedia dot com
` (21 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-08-15 10:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #42 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Sven C. Dack from comment #40)
> The results are the averages (and deviations) of 5 runs with each compiler:
>
> avg stdev %
> default: 282.86s 0.56s, 0.20% 100.00% (base)
> profiled: 255.76s 0.72s, 0.28% +10.60%
> lto: 282.80s 0.16s, 0.06% +0.02%
> lto-plugin: 285.41s 0.49s, 0.17% -0.89%
Can you also try profiled+lto? This should in theory get you the fastes
compiler.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (36 preceding siblings ...)
2014-08-15 10:44 ` trippels at gcc dot gnu.org
@ 2014-08-15 10:56 ` sven.c.dack at virginmedia dot com
2014-08-15 11:37 ` trippels at gcc dot gnu.org
` (20 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-15 10:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #43 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
(In reply to Markus Trippelsdorf from comment #42)
> (In reply to Sven C. Dack from comment #40)
> > The results are the averages (and deviations) of 5 runs with each compiler:
> >
> > avg stdev %
> > default: 282.86s 0.56s, 0.20% 100.00% (base)
> > profiled: 255.76s 0.72s, 0.28% +10.60%
> > lto: 282.80s 0.16s, 0.06% +0.02%
> > lto-plugin: 285.41s 0.49s, 0.17% -0.89%
>
> Can you also try profiled+lto? This should in theory get you the fastes
> compiler.
I am already on it, but it will take a while.
I had assumed this would not work yet. I also read that with only LTO one would
get a faster compiler. Why is this not the case here?
The binutils I am using are:
$ ld --version
GNU ld (GNU Binutils) 2.24.51.20140703
Copyright (C) 2014 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (37 preceding siblings ...)
2014-08-15 10:56 ` sven.c.dack at virginmedia dot com
@ 2014-08-15 11:37 ` trippels at gcc dot gnu.org
2014-08-15 17:28 ` jason at gcc dot gnu.org
` (19 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: trippels at gcc dot gnu.org @ 2014-08-15 11:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #44 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Sven C. Dack from comment #43)
> (In reply to Markus Trippelsdorf from comment #42)
> > (In reply to Sven C. Dack from comment #40)
> > > The results are the averages (and deviations) of 5 runs with each compiler:
> > >
> > > avg stdev %
> > > default: 282.86s 0.56s, 0.20% 100.00% (base)
> > > profiled: 255.76s 0.72s, 0.28% +10.60%
> > > lto: 282.80s 0.16s, 0.06% +0.02%
> > > lto-plugin: 285.41s 0.49s, 0.17% -0.89%
> >
> > Can you also try profiled+lto? This should in theory get you the fastes
> > compiler.
>
> I am already on it, but it will take a while.
>
> I had assumed this would not work yet. I also read that with only LTO one
> would get a faster compiler.
Not in my experience. As you've found out LTO is good for reducing
binary sizes, but it really needs PGO to make sensible decisions.
BTW if you have TCMalloc installed on your machine, appending
"POSTSTAGE1_LDFLAGS += -l/usr/lib/libtcmalloc.so.4" to config/bootstrap-lto.mk
may give you an additional 8-10% speed boost (at least for big C++ projects,
I haven't measured kernel build times).
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (38 preceding siblings ...)
2014-08-15 11:37 ` trippels at gcc dot gnu.org
@ 2014-08-15 17:28 ` jason at gcc dot gnu.org
2014-08-15 20:02 ` sven.c.dack at virginmedia dot com
` (18 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: jason at gcc dot gnu.org @ 2014-08-15 17:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #45 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Fri Aug 15 17:27:58 2014
New Revision: 214030
URL: https://gcc.gnu.org/viewcvs?rev=214030&root=gcc&view=rev
Log:
PR bootstrap/62077
gcc/
* tree.c (type_hash_canon): Uncomment assert.
gcc/cp/
* tree.c (build_min_array_type, set_array_type_canon): Split out...
(build_cplus_array_type): ...from here. Only call build_array_type
for main variants.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/tree.c
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (39 preceding siblings ...)
2014-08-15 17:28 ` jason at gcc dot gnu.org
@ 2014-08-15 20:02 ` sven.c.dack at virginmedia dot com
2014-08-15 20:07 ` sven.c.dack at virginmedia dot com
` (17 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-15 20:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #46 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
> ...
> > > > avg stdev %
> > > > default: 282.86s 0.56s, 0.20% 100.00% (base)
> > > > profiled: 255.76s 0.72s, 0.28% +10.60%
> > > > lto: 282.80s 0.16s, 0.06% +0.02%
> > > > lto-plugin: 285.41s 0.49s, 0.17% -0.89%
> ...
> Not in my experience. As you've found out LTO is good for reducing
> binary sizes, but it really needs PGO to make sensible decisions.
These are the new results (5 runs). I have dropped "lto-plugin" and added
"profiled-lto":
avg stdev %
default: 282.13s 0.71, 0.25% 100.00% (base)
profiled: 255.29s 0.80, 0.31% +10.52%
lto: 281.71s 0.70, 0.25% +0.15%
profiled-lto: 251.38s 0.49, 0.19% +12.23%
gmp, mpfr and mpc have been compiled without LTO.
> BTW if you have TCMalloc installed on your machine, appending
> "POSTSTAGE1_LDFLAGS += -l/usr/lib/libtcmalloc.so.4" to
> config/bootstrap-lto.mk
> may give you an additional 8-10% speed boost (at least for big C++ projects,
> I haven't measured kernel build times).
This is going off the topic, but I do not mean to disrespect you. I did not use
it in the test runs. You may want to look at "lockless malloc". It seems to be
all round better, because TCMalloc requires a very specific additional library
(libunwind-0.99-beta) and has got problems with glibc and locking, too.
"lockless malloc" is free of locking, very small, available as GPLv3 open
source and said be be faster than TCMalloc. See here:
http://locklessinc.com/benchmarks_allocator.shtml
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (40 preceding siblings ...)
2014-08-15 20:02 ` sven.c.dack at virginmedia dot com
@ 2014-08-15 20:07 ` sven.c.dack at virginmedia dot com
2014-08-17 8:19 ` sven.c.dack at virginmedia dot com
` (16 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-15 20:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #47 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
> default: 84920k
> profiled: 90176k
> lto: 71204k
> lto-plugin: 60024k
The new file sizes of cc1's are:
default: 84920k
profiled: 90176k
lto: 71204k
profiled-lto: 98556k
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (41 preceding siblings ...)
2014-08-15 20:07 ` sven.c.dack at virginmedia dot com
@ 2014-08-17 8:19 ` sven.c.dack at virginmedia dot com
2014-08-17 10:55 ` sven.c.dack at virginmedia dot com
` (15 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-17 8:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #48 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
> ...
> > With the linker plugin enabled does it actually link libgcc_s.so and
> > libstdc++.so dynamically to it, while for the other three it did not:
>
> That looks odd. Btw, -fuse-linker-plugin should be the default
> if you have recent enough binutils.
>
> Richard
I have been trying to get around this oddity by creating a statically linked
compiler, but I keep running into the same problem. Is the building of a
statically linked gcc (with lto and linker plugin enabled) actually supported?
I keep using --with-boot-ldflags="... -static -fuse-linker-plugin", but get the
message:
"xgcc: error: -fuse-linker-plugin is not supported in this configuration"
This happens while make is configuring for stage 3:
...
rm -f stage_current
make[3]: Leaving directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin'
make[2]: Leaving directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin'
make[2]: Entering directory '/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin'
Configuring stage 3 in ./lto-plugin
Configuring stage 3 in ./zlib
Configuring stage 3 in ./intl
Configuring stage 3 in ./libdecnumber
Configuring stage 3 in ./libiberty
Configuring stage 3 in ./libbacktrace
...
$ more libbacktrace/config.log
...
configure:2936: checking for C compiler default output file name
configure:2958:
/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc
-B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/ -B/home
/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem
/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem
/home/sven/gcc-lto-plu
gin/x86_64-unknown-linux-gnu/sys-include -g -O2 -flto=jobserver
-frandom-seed=1 -ffat-lto-objects -static -flto=1 -flto-partition=none
-fuse-linker-plugin conftest.c >&5
xgcc: error: -fuse-linker-plugin is not supported in this configuration
...
It can be seen for all the directories that are being configured for stage 3.
Without "-fuse-linker-plugin" does it create a compiler and it also works for a
non-static build.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (42 preceding siblings ...)
2014-08-17 8:19 ` sven.c.dack at virginmedia dot com
@ 2014-08-17 10:55 ` sven.c.dack at virginmedia dot com
2014-08-17 15:49 ` sven.c.dack at virginmedia dot com
` (14 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-17 10:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #49 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
The problem seems to be a missing liblto_plugin.so in gcc's directory for
stage2. I used:
--with-boot-ldflags="-static -flto=1 -flto-partition=none -fuse-linker-plugin"
together with:
--enable-linker-plugin-flags="-pipe -O2 -march=native -fomit-frame-pointer
-fno-builtin-memcmp"
to avoid the "-static" option from being passed onto the plugin, but it fails.
During stage1 does it still work and builds liblto_plugin.so as follows:
...
/bin/bash ./libtool --tag=CC --tag=disable-static --mode=compile gcc
-DHAVE_CONFIG_H -I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin
lto-plugin -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin
../include -DHAVE_CONFIG_H -Wall -g -c -o lto-plugin.lo
/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin
-I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include
-DHAVE_CONFIG_H -Wall -g -c
/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c -fPIC
-DPIC -o .libs/lto-plugin.o
/bin/bash ./libtool --tag=CC --tag=disable-static --mode=link gcc -Wall -g
-Wc,-static-libgcc -module -bindir
/home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2
-static-libstdc++ -static-libgcc -pipe -O2 -march=native -fomit-frame-pointer
-fno-builtin-memcmp -o liblto_plugin.la -rpath
/home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2
lto-plugin.lo -Wc,../libiberty/pic/libiberty.a
libtool: link: gcc -shared .libs/lto-plugin.o -static-libgcc -march=native
../libiberty/pic/libiberty.a -Wl,-soname -Wl,liblto_plugin.so.0 -o
.libs/liblto_plugin.so.0.0.0
libtool: link: (cd ".libs" && rm -f "liblto_plugin.so.0" && ln -s
"liblto_plugin.so.0.0.0" "liblto_plugin.so.0")
libtool: link: (cd ".libs" && rm -f "liblto_plugin.so" && ln -s
"liblto_plugin.so.0.0.0" "liblto_plugin.so")
libtool: link: ( cd ".libs" && rm -f "liblto_plugin.la" && ln -s
"../liblto_plugin.la" "liblto_plugin.la" )
...
This leads to stage1 having a working plugin. For stage2 does it change:
/bin/bash ./libtool --tag=CC --tag=disable-static --mode=compile
/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc
-B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem
/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem
/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include
-DHAVE_CONFIG_H -I.
-I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin
-I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include
-DHAVE_CONFIG_H -Wall -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects
-c -o lto-plugin.lo
/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c
...
This already looks wrong. Although it has removed "-static" from the options is
it actually using those I have given with --with-boot-ldflags="..." and it is
not using those given with --enable-linker-plugin-flags="...". It continues
with:
libtool: compile:
/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc
-B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem
/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem
/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H
-I. -I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin
-I/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/../include
-DHAVE_CONFIG_H -Wall -g -O2 -flto=jobserver -frandom-seed=1 -ffat-lto-objects
-c /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/lto-plugin.c
-fPIC -DPIC -o .libs/lto-plugin.o
# (line B)
/bin/bash ./libtool --tag=CC --tag=disable-static --mode=link
/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/xgcc
-B/var/tmp/build-pkg-32413/obj/gcc-4.9-lto-plugin/./prev-gcc/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/bin/
-B/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/lib/ -isystem
/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/include -isystem
/home/sven/gcc-lto-plugin/x86_64-unknown-linux-gnu/sys-include -Wall -g -O2
-flto=jobserver -frandom-seed=1 -ffat-lto-objects -Wc,-static-libgcc -module
-bindir /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2
-static -flto=1 -flto-partition=none -fuse-linker-plugin -o liblto_plugin.la
-rpath /home/sven/gcc-lto-plugin/libexec/gcc/x86_64-unknown-linux-gnu/4.9.2
lto-plugin.lo -Wc,../libiberty/pic/libiberty.a
libtool: link: ar rc .libs/liblto_plugin.a .libs/lto-plugin.o
libtool: link: ranlib .libs/liblto_plugin.a
libtool: link: ( cd ".libs" && rm -f "liblto_plugin.la" && ln -s
"../liblto_plugin.la" "liblto_plugin.la" )
WARNING: liblto_plugin.la is static, not copying to .././gcc/liblto_plugin.la
Why is it not using the options given with --enable-linker-plugin-flags for the
2nd stage?
config.log for stage1 and stage2 both show that --enable-linker-plugin-flags
has been passed to configure:
$ head -7 stage1-lto-plugin/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by LTO plugin for ld configure 0.1, which was
generated by GNU Autoconf 2.64. Invocation command line was
$ /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/configure
--cache-file=./config.cache --prefix=/home/sven/gcc-lto-plugin
--with-gmp=/home/sven/gcc-lto-plugin --with-mpfr=/home/sven/gcc-lto-plugin
--with-mpc=/home/sven/gcc-lto-plugin --enable-stage1-languages=c,lto
--enable-multiarch --with-arch=native --enable-checking=yes
--enable-stage1-checking=yes --enable-linker-build-id
--with-linker-hash-style=gnu --enable-lto --with-build-config=bootstrap-lto
--enable-link-mutex --enable-linker-plugin-flags=-pipe -O2 -march=native
-fomit-frame-pointer -fno-builtin-memcmp --with-boot-ldflags=-static -flto=1
-flto-partition=none -fuse-linker-plugin --enable-languages=c,c++,lto
--program-transform-name=s,y,y, --disable-option-checking
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
--srcdir=/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin
--disable-intermodule --enable-checking=yes --disable-coverage
--enable-languages=c,c++,lto --disable-build-format-warnings --enable-shared
$ head -7 prev-lto-plugin/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by LTO plugin for ld configure 0.1, which was
generated by GNU Autoconf 2.64. Invocation command line was
$ /var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin/configure
--cache-file=./config.cache --prefix=/home/sven/gcc-lto-plugin
--with-gmp=/home/sven/gcc-lto-plugin --with-mpfr=/home/sven/gcc-lto-plugin
--with-mpc=/home/sven/gcc-lto-plugin --enable-stage1-languages=c,lto
--enable-multiarch --with-arch=native --enable-checking=yes
--enable-stage1-checking=yes --enable-linker-build-id
--with-linker-hash-style=gnu --enable-lto --with-build-config=bootstrap-lto
--enable-link-mutex --enable-linker-plugin-flags=-pipe -O2 -march=native
-fomit-frame-pointer -fno-builtin-memcmp --with-boot-ldflags=-static -flto=1
-flto-partition=none -fuse-linker-plugin --enable-languages=c,c++,lto
--program-transform-name=s,y,y, --disable-option-checking
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
--srcdir=/var/tmp/build-pkg-32413/src/gcc-4.9-lto-plugin/lto-plugin
--with-build-libsubdir=. --enable-shared
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (43 preceding siblings ...)
2014-08-17 10:55 ` sven.c.dack at virginmedia dot com
@ 2014-08-17 15:49 ` sven.c.dack at virginmedia dot com
2014-08-18 11:00 ` venkataramanan.kumar at amd dot com
` (13 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-17 15:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #50 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
The additional configuration options --enable-linker-plugin-configure-flags=
and --enable-linker-plugin-flags=, which I have trusted in and taken from
https://gcc.gnu.org/install/configure.html do not seem to exist in 4.9, but
only exist with the upcoming 4.10. Someone has been fast with the web updates
and now one cannot trust them for building a stable compiler *sigh*.
Anyhow, it explains why I cannot bootstrap a statically linked compiler with
lto and linker plugin.
Will this be taken care of for 4.9.2? And can I leave this here or shall I make
a new report for it?
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (44 preceding siblings ...)
2014-08-17 15:49 ` sven.c.dack at virginmedia dot com
@ 2014-08-18 11:00 ` venkataramanan.kumar at amd dot com
2014-08-18 13:11 ` rguenther at suse dot de
` (12 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-18 11:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #51 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
(In reply to rguenther@suse.de from comment #35)
> On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> >
> > --- Comment #34 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
> > Richard, What I understand is that instead of using tune flags for garbage
> > collection, need to try and fix the object code differences?
>
> Yes, it points at real bugs. OTOH fixing that may not be suitable
> for the release branches, neither is passing fixed values for GC
> parameters. So I'm not quite sure what a suitable workaround is
> (well, make sure !defined ENABLE_GC_CHECKING && !defined
> ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2
> for bootstrap-lto, that is, init_ggc_heuristics () is executed
> in the same way)
Hi richard,
In Stage1 we add --enable-checking=yes,types and it sets ENABLE_GC_CHECKING as
true
In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So the
check "#if !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT"
will be true for stage2 only.
ENABLE_GC_ALWAYS_COLLECT is false in both stages.
Do we need to make sure stage 1 and stage 2 executes the function
init_ggc_heuristics and will it set the parameters to same value?
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (45 preceding siblings ...)
2014-08-18 11:00 ` venkataramanan.kumar at amd dot com
@ 2014-08-18 13:11 ` rguenther at suse dot de
2014-08-18 13:36 ` venkataramanan.kumar at amd dot com
` (11 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenther at suse dot de @ 2014-08-18 13:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #52 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> --- Comment #51 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
> (In reply to rguenther@suse.de from comment #35)
> > On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> > >
> > > --- Comment #34 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
> > > Richard, What I understand is that instead of using tune flags for garbage
> > > collection, need to try and fix the object code differences?
> >
> > Yes, it points at real bugs. OTOH fixing that may not be suitable
> > for the release branches, neither is passing fixed values for GC
> > parameters. So I'm not quite sure what a suitable workaround is
> > (well, make sure !defined ENABLE_GC_CHECKING && !defined
> > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2
> > for bootstrap-lto, that is, init_ggc_heuristics () is executed
> > in the same way)
>
> Hi richard,
>
> In Stage1 we add --enable-checking=yes,types and it sets ENABLE_GC_CHECKING as
> true
>
> In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So the
> check "#if !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT"
> will be true for stage2 only.
>
> ENABLE_GC_ALWAYS_COLLECT is false in both stages.
>
> Do we need to make sure stage 1 and stage 2 executes the function
> init_ggc_heuristics and will it set the parameters to same value?
Well, it would be a workaround only. The real fix is to track down
and fix all remaining issues we have with regarding to IL differences
caused by collection changes.
First one is fixed, 2nd one is not yet tracked down completely
(feel free to continue - it takes a lot of time and I have other
stuff to do right now)
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (46 preceding siblings ...)
2014-08-18 13:11 ` rguenther at suse dot de
@ 2014-08-18 13:36 ` venkataramanan.kumar at amd dot com
2014-08-18 13:40 ` rguenther at suse dot de
` (10 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: venkataramanan.kumar at amd dot com @ 2014-08-18 13:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #53 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
Hi Richard,
>> Well, it would be a workaround only. The real fix is to track down and fix all remaining issues we have with regarding to IL differences caused by collection changes.
In your earlier comment you mentioned that
> OTOH fixing that may not be suitable
> for the release branches, neither is passing fixed values for GC
> parameters.
So for release branch 4.9 shall we go for this workaround patch ?
> First one is fixed, 2nd one is not yet tracked down completely (feel free to continue - it takes a lot of time and I have other stuff to do right now)
I am new to LTO but would love to work learn and contribute :)
Thanks
Venkat.
-----Original Message-----
From: rguenther at suse dot de [mailto:gcc-bugzilla@gcc.gnu.org]
Sent: Monday, August 18, 2014 6:41 PM
To: Kumar, Venkataramanan
Subject: [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #52 from rguenther at suse dot de <rguenther at suse dot de> --- On
Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> --- Comment #51 from Venkataramanan <venkataramanan.kumar at amd dot
> com> --- (In reply to rguenther@suse.de from comment #35)
> > On Thu, 14 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
> > >
> > > --- Comment #34 from Venkataramanan <venkataramanan.kumar at amd
> > > dot com> --- Richard, What I understand is that instead of using
> > > tune flags for garbage collection, need to try and fix the object code differences?
> >
> > Yes, it points at real bugs. OTOH fixing that may not be suitable
> > for the release branches, neither is passing fixed values for GC
> > parameters. So I'm not quite sure what a suitable workaround is
> > (well, make sure !defined ENABLE_GC_CHECKING && !defined
> > ENABLE_GC_ALWAYS_COLLECT is consistent between stage1 and stage2 for
> > bootstrap-lto, that is, init_ggc_heuristics () is executed in the
> > same way)
>
> Hi richard,
>
> In Stage1 we add --enable-checking=yes,types and it sets
> ENABLE_GC_CHECKING as true
>
> In Stage2 for release branches it sets ENABLE_GC_CHECKING as false. So
> the check "#if !defined ENABLE_GC_CHECKING && !defined ENABLE_GC_ALWAYS_COLLECT"
> will be true for stage2 only.
>
> ENABLE_GC_ALWAYS_COLLECT is false in both stages.
>
> Do we need to make sure stage 1 and stage 2 executes the function
> init_ggc_heuristics and will it set the parameters to same value?
Well, it would be a workaround only. The real fix is to track down and fix all
remaining issues we have with regarding to IL differences caused by collection
changes.
First one is fixed, 2nd one is not yet tracked down completely (feel free to
continue - it takes a lot of time and I have other stuff to do right now)
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (47 preceding siblings ...)
2014-08-18 13:36 ` venkataramanan.kumar at amd dot com
@ 2014-08-18 13:40 ` rguenther at suse dot de
2014-08-18 15:03 ` sven.c.dack at virginmedia dot com
` (9 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenther at suse dot de @ 2014-08-18 13:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #54 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 18 Aug 2014, venkataramanan.kumar at amd dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> --- Comment #53 from Venkataramanan <venkataramanan.kumar at amd dot com> ---
> Hi Richard,
>
> >> Well, it would be a workaround only. The real fix is to track down and fix all remaining issues we have with regarding to IL differences caused by collection changes.
>
> In your earlier comment you mentioned that
>
> > OTOH fixing that may not be suitable
> > for the release branches, neither is passing fixed values for GC
> > parameters.
>
> So for release branch 4.9 shall we go for this workaround patch ?
I don't see why we need to fix this for the 4.9 or 4.8 branch. It
never worked there and another existing workaround is to configure
with --enable-stage1-checking=release.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (48 preceding siblings ...)
2014-08-18 13:40 ` rguenther at suse dot de
@ 2014-08-18 15:03 ` sven.c.dack at virginmedia dot com
2015-04-15 7:30 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: sven.c.dack at virginmedia dot com @ 2014-08-18 15:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #56 from Sven C. Dack <sven.c.dack at virginmedia dot com> ---
> I don't see why we need to fix this for the 4.9 or 4.8 branch. It never
> worked there and another existing workaround is to configure with
> --enable-stage1-checking=release.
One reason is that it is not working in any of the recent stable compilers. 5.0
is not stable yet and said to be release not before next year.
At least one of the stable compilers should be able to bootstrap itself with
LTO, because it is one of the primary features in its latest development. It
just looks bad when it fails and will discourage people from adopting it. You
do want GCC users to make use of all its features. Why else put them in there
in the first place, or just make them wait, when it is easy to fix?
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (49 preceding siblings ...)
2014-08-18 15:03 ` sven.c.dack at virginmedia dot com
@ 2015-04-15 7:30 ` rguenth at gcc dot gnu.org
2015-04-15 7:49 ` vekumar at gcc dot gnu.org
` (7 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-04-15 7:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Known to fail| |4.8.4, 4.9.2, 5.1.0
--- Comment #57 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bootstrap with LTO fails for me on the GCC 5 branch now as well (thus, with
--enable-checking=release --enable-stage1-checking=yes).
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (50 preceding siblings ...)
2015-04-15 7:30 ` rguenth at gcc dot gnu.org
@ 2015-04-15 7:49 ` vekumar at gcc dot gnu.org
2015-04-15 8:12 ` rguenther at suse dot de
` (6 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: vekumar at gcc dot gnu.org @ 2015-04-15 7:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
vekumar at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vekumar at gcc dot gnu.org
--- Comment #58 from vekumar at gcc dot gnu.org ---
Richard,
So for GCC 5.0 branch we has to use --enable-stage1-checking=release as
workaround?
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (51 preceding siblings ...)
2015-04-15 7:49 ` vekumar at gcc dot gnu.org
@ 2015-04-15 8:12 ` rguenther at suse dot de
2015-04-15 8:34 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenther at suse dot de @ 2015-04-15 8:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #59 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 15 Apr 2015, vekumar at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
>
> vekumar at gcc dot gnu.org changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |vekumar at gcc dot gnu.org
>
> --- Comment #58 from vekumar at gcc dot gnu.org ---
> Richard,
>
> So for GCC 5.0 branch we has to use --enable-stage1-checking=release as
> workaround?
I'm currently verifying if that works, yes.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (52 preceding siblings ...)
2015-04-15 8:12 ` rguenther at suse dot de
@ 2015-04-15 8:34 ` rguenth at gcc dot gnu.org
2015-04-17 11:04 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-04-15 8:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #60 from Richard Biener <rguenth at gcc dot gnu.org> ---
Workaround confirmed for GCC 5 (--enable-stage1-checking=release).
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (53 preceding siblings ...)
2015-04-15 8:34 ` rguenth at gcc dot gnu.org
@ 2015-04-17 11:04 ` jakub at gcc dot gnu.org
2015-04-17 11:28 ` rguenth at gcc dot gnu.org
` (3 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-17 11:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #61 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #60)
> Workaround confirmed for GCC 5 (--enable-stage1-checking=release).
So, what about just use the workaround automatically for the default
--enable-stage1-checking (of course, if somebody uses something explicitly, he
is on his own)?
Like:
--- configure.ac.jj 2015-03-27 18:32:41.000000000 +0100
+++ configure.ac 2015-04-17 13:01:30.117314053 +0200
@@ -3482,7 +3482,19 @@ AC_ARG_ENABLE(stage1-checking,
[choose additional checking for stage1 of the compiler])],
[stage1_checking=--enable-checking=${enable_stage1_checking}],
[if test "x$enable_checking" = xno || test "x$enable_checking" = x; then
- stage1_checking=--enable-checking=yes,types
+ # For --disable-checking or implicit --enable-checking=release, avoid
+ # setting --enable-checking=gc in the default stage1 checking for LTO
+ # bootstraps. See PR62077.
+ stage1_checking=--enable-checking=release,misc,gimple,rtlflag,tree,types
+ case $BUILD_CONFIG in
+ *lto*)
+ if test "x$enable_checking" = x && \
+ test -d ${srcdir}/gcc && \
+ test x"`cat ${srcdir}/gcc/DEV-PHASE`" = xexperimental; then
+ stage1_checking=--enable-checking=yes,types
+ fi;;
+ *) stage1_checking=--enable-checking=yes,types;;
+ esac
else
stage1_checking=--enable-checking=$enable_checking,types
fi])
I've so far successfully bootstrapped GCC 5 branch with
../configure --prefix=/tmp/blah --with-gnu-as --with-gnu-ld
--enable-languages=all,go --disable-multilib --disable-nls --with-arch=haswell
--with-tune=haswell --with-build-config=bootstrap-lto
--enable-stage1-checking=release,misc,gimple,rtlflag,tree,types
so it indeed is the gc checking that breaks the LTO bootstrap comparison.
release,misc,gimple,rtlflag,tree,types I believe enables everything yes,types
enables, except for gc checking.
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (54 preceding siblings ...)
2015-04-17 11:04 ` jakub at gcc dot gnu.org
@ 2015-04-17 11:28 ` rguenth at gcc dot gnu.org
2015-04-17 17:10 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
58 siblings, 0 replies; 60+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-04-17 11:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #62 from Richard Biener <rguenth at gcc dot gnu.org> ---
Works for me. Of course we should hunt down IL differences that appear with
GC.
It's just a lurking bug that can hit the non-GC checking path as well.
But all this is exceptionally hard to track down :/
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (55 preceding siblings ...)
2015-04-17 11:28 ` rguenth at gcc dot gnu.org
@ 2015-04-17 17:10 ` jakub at gcc dot gnu.org
2015-04-17 17:11 ` jakub at gcc dot gnu.org
2015-05-06 14:47 ` hjl.tools at gmail dot com
58 siblings, 0 replies; 60+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-17 17:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #63 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Fri Apr 17 17:09:20 2015
New Revision: 222187
URL: https://gcc.gnu.org/viewcvs?rev=222187&root=gcc&view=rev
Log:
PR bootstrap/62077
* configure.ac (--enable-stage1-checking): Default to
release,misc,gimple,rtlflag,tree,types if --disable-checking
or --enable-checking is not specified and DEV-PHASE is not
experimental.
* configure: Regenerated.
Modified:
trunk/ChangeLog
trunk/configure
trunk/configure.ac
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (56 preceding siblings ...)
2015-04-17 17:10 ` jakub at gcc dot gnu.org
@ 2015-04-17 17:11 ` jakub at gcc dot gnu.org
2015-05-06 14:47 ` hjl.tools at gmail dot com
58 siblings, 0 replies; 60+ messages in thread
From: jakub at gcc dot gnu.org @ 2015-04-17 17:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
--- Comment #64 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Fri Apr 17 17:10:27 2015
New Revision: 222189
URL: https://gcc.gnu.org/viewcvs?rev=222189&root=gcc&view=rev
Log:
PR bootstrap/62077
* configure.ac (--enable-stage1-checking): Default to
release,misc,gimple,rtlflag,tree,types if --disable-checking
or --enable-checking is not specified and DEV-PHASE is not
experimental.
* configure: Regenerated.
Modified:
branches/gcc-5-branch/ChangeLog
branches/gcc-5-branch/configure
branches/gcc-5-branch/configure.ac
^ permalink raw reply [flat|nested] 60+ messages in thread* [Bug bootstrap/62077] --with-build-config=bootstrap-lto fails
2014-08-09 20:55 [Bug bootstrap/62077] New: --with-build-config=bootstrap-lto fails, sven.c.dack at virginmedia dot com
` (57 preceding siblings ...)
2015-04-17 17:11 ` jakub at gcc dot gnu.org
@ 2015-05-06 14:47 ` hjl.tools at gmail dot com
58 siblings, 0 replies; 60+ messages in thread
From: hjl.tools at gmail dot com @ 2015-05-06 14:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62077
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hjl.tools at gmail dot com
Version|lto |5.1.1
--- Comment #65 from H.J. Lu <hjl.tools at gmail dot com> ---
GCC 5 branch on Linux/x86-64 with
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
--prefix=/usr/local --enable-gnu-indirect-function --disable-werror
--with-build-config=bootstrap-lto --with-fpmath=sse
I got
gcc/except.o differs
gcc/build/genconfig.o differs
gcc/build/genpeep.o differs
gcc/tree-cfg.o differs
gcc/tree-ssa-loop-ivcanon.o differs
gcc/tree-inline.o differs
gcc/dbxout.o differs
gcc/web.o differs
gcc/sel-sched-ir.o differs
gcc/reload1.o differs
gcc/function.o differs
gcc/tree-vrp.o differs
gcc/tree-diagnostic.o differs
gcc/dumpfile.o differs
gcc/dwarf2cfi.o differs
gcc/regcprop.o differs
gcc/tree.o differs
gcc/lto-streamer-out.o differs
gcc/cfgexpand.o differs
gcc/ipa-devirt.o differs
gcc/tree-ssa-propagate.o differs
gcc/ipa-inline-analysis.o differs
gcc/java/lang.o differs
gcc/java/expr.o differs
gcc/tree-outof-ssa.o differs
gcc/tree-eh.o differs
gcc/emit-rtl.o differs
gcc/cfgloop.o differs
gcc/tree-ssa-pre.o differs
gcc/cfgloopmanip.o differs
gcc/lto-cgraph.o differs
gcc/objc/objc-act.o differs
gcc/varasm.o differs
gcc/cp/pt.o differs
gcc/cp/class.o differs
gcc/cp/name-lookup.o differs
gcc/cp/cp-gimplify.o differs
gcc/cp/semantics.o differs
gcc/cp/parser.o differs
gcc/sched-rgn.o differs
gcc/c/c-parser.o differs
gcc/c/c-typeck.o differs
gcc/gimple-low.o differs
gcc/sel-sched.o differs
gcc/tree-ssa-uninit.o differs
gcc/coverage.o differs
gcc/omp-low.o differs
gcc/gimple.o differs
gcc/c-family/c-ada-spec.o differs
gcc/c-family/c-pragma.o differs
gcc/dwarf2out.o differs
gcc/tree-switch-conversion.o differs
gcc/cfgrtl.o differs
gcc/i386.o differs
libcpp/lex.o differs
^ permalink raw reply [flat|nested] 60+ messages in thread