On 14.11.12 21:57, Peter Bergner wrote:
> On Wed, 2012-11-14 at 18:51 +0100, Andreas Tobler wrote:
>> Hello,
>>
>> on trunk (193501) I get a comparison failure:
>> ---
>> Bootstrap comparison failure!
>> gcc/tree-ssa-forwprop.o differs
>> ---
>>
On Wed, 2012-11-14 at 18:51 +0100, Andreas Tobler wrote:
> Hello,
>
> on trunk (193501) I get a comparison failure:
> ---
> Bootstrap comparison failure!
> gcc/tree-ssa-forwprop.o differs
> ---
>
> This is with --disable-checking. Leaving disable-checking away
Hello,
on trunk (193501) I get a comparison failure:
---
Bootstrap comparison failure!
gcc/tree-ssa-forwprop.o differs
---
This is with --disable-checking. Leaving disable-checking away, the
bootstrap completes succesfully.
---
andreast% stage2-gcc/xgcc -v
Using built-in specs.
COLLECT_GCC
On 03-27 09:42, Andi Kleen wrote:
> Witold Baryluk writes:
> >
> > make BOOT_CFLAGS="$CFLAGS -flto" CFLAGS_FOR_BUILD="$CFLAGS"
> > CXXFLAGS_FOR_BUILD="$CXXFLAGS" bootstrap
>
> Easier is to configure with --with-build-config=bootstrap-lto
> then you don't need all the magic CFLAGS lines.
As you s
> Is this because I manually changed BOOT_CFLAGS as passed to make?
As previously said, you ought to avoid fiddling with BOOT_CFLAGS in any case.
Configure --with-build-config=bootstrap-lto --with-fpmath=sse --with-arch=xxx
and so on, and just type "make".
> And why it took so long?
Probably
Witold Baryluk writes:
>
> make BOOT_CFLAGS="$CFLAGS -flto" CFLAGS_FOR_BUILD="$CFLAGS"
> CXXFLAGS_FOR_BUILD="$CXXFLAGS" bootstrap
Easier is to configure with --with-build-config=bootstrap-lto
then you don't need all the magic CFLAGS lines.
> And then waited
>
> I actually waited 5 days... (e
math=sse -flto -flto=jobserver -frandom-seed=1" "STAGE3_CXXFLAGS=-O3
-march=core2 -Wl,-O1 -mfpmath=sse -flto -f
lto=jobserver -frandom-seed=1" "STAGE3_TFLAGS=" "STAGE4_CFLAGS=-O3 -march=core2
-Wl,-O1 -mfpmath=sse -flto" "STAG
E4_CXXFLAGS=-O3 -march=core2 -
Jan Hubicka writes:
> The problem is that GCC produce constructors/destructors at various places
> and they all used to be called GLOBAL__I
> and GLOBAL__D. Then in some cases (on targets that don't have global
> ctors/dtors or with LTO and ctor/dtor merging)
> it actually collect them into si
> I don't understand this at all.
>
> I thought you were saying that these are static functions, and that gcc
> gathers them all together into a single global constructor. Are there
> cases where gcc does not gather them together? Why would that be?
At the moment we don't gather when there is o
Jan Hubicka writes:
> 2) Do the actual renaming of _GLOBAL__I into something else (fully local
> name like static_ctor.1234 at a time it is being inserted
> into merged ctor.
>
> We can't avoid producing these names early since on target that havecdtors
> we avoid producing merged c
> Jan Hubicka writes:
>
> > The problem is that GCC produce constructors/destructors at various places
> > and they all used to be called GLOBAL__I
> > and GLOBAL__D. Then in some cases (on targets that don't have global
> > ctors/dtors or with LTO and ctor/dtor merging)
> > it actually collec
Jan Hubicka writes:
>> Jan Hubicka writes:
>>
>> > I think bootstrap with C++ or GO is broken for a while on targets not
>> > having ctor support, but now it broke
>> > on targets with ctor support as a result of my patch renaming some of the
>> > ctors from GLOBAL__I into GLOBAL__sub_I.
>>
> Now if this breaks other logic in ld & friends on have_cdtor targets, I guess
> we could
0) return to always inlining on non_have_cdtors targets and hope for the
best :)
> 1) du _sub_I/sub_D mangling only on targets not having ctors/dtors where
> merged constructor is always produced
>
> > Jan Hubicka writes:
> >
> > > I think bootstrap with C++ or GO is broken for a while on targets not
> > > having ctor support, but now it broke
> > > on targets with ctor support as a result of my patch renaming some of the
> > > ctors from GLOBAL__I into GLOBAL__sub_I.
> >
> > I didn't kn
> Jan Hubicka writes:
>
> > I think bootstrap with C++ or GO is broken for a while on targets not
> > having ctor support, but now it broke
> > on targets with ctor support as a result of my patch renaming some of the
> > ctors from GLOBAL__I into GLOBAL__sub_I.
>
> I didn't know you were maki
Jan Hubicka writes:
> I think bootstrap with C++ or GO is broken for a while on targets not having
> ctor support, but now it broke
> on targets with ctor support as a result of my patch renaming some of the
> ctors from GLOBAL__I into GLOBAL__sub_I.
I didn't know you were making that change.
On Wed, 2010-12-15 at 13:57 +0100, Jan Hubicka wrote:
> Hi,
> the problem is that we special case constructors and avoid random seed on
> them on targets that have global ctors.
> I think bootstrap with C++ or GO is broken for a while on targets not having
> ctor support, but now it broke
> on ta
Hi,
the problem is that we special case constructors and avoid random seed on them
on targets that have global ctors.
I think bootstrap with C++ or GO is broken for a while on targets not having
ctor support, but now it broke
on targets with ctor support as a result of my patch renaming some of t
> -696
> .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_14146711
> 00b6 00011580 2**4
> +696
> .text.startup._GLOBAL__sub_I_.._.._.._.._gccgo_git_libstdc___v3_src_wlocale_inst.cc_76D38880_EB7C2B89
> 00b6
I believe, something broke the trunk tip build recently:
Comparing stages 2 and 3
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/wlocale-inst.o differs
x86_64-unknown-linux-gnu/libstdc++-v3
checksum.o differs
Bootstrap comparison failure!
gcc/reg-stack.o differs
gcc/i386.o differs
gcc/reload.o differs
gcc/recog.o differs
gcc/dwarf2out.o differs
libiberty/hashtab.o differs
Source Information:
Revision 162274
No modifications.
Build Environment:
GNU/Linux 2.6.35-r
Ralf Wildenhues wrote:
> Comparing stages 2 and 3
> Bootstrap comparison failure!
> Now, what do I do to (help) debug this? Open a PR? Attach some of the
> object files (which)?
Well, ultimately, you could rebuild everything with --save-temps and take a
look at the .s
able-sim' '--enable-gold' '--enable-build-with-cxx'
'CC=/home/ralf/recent/bin/gcc' 'CXX=/home/ralf/recent/bin/g++'
'--enable-languages=c,c++,fortran,java,objc,obj-c++'"
and a very recent GCC as $build compiler:
| gcc (GCC) 4.5.0 20090916 (
On Sat, 12 Sep 2009 13:29:35 +0200 (CEST)
Gerald Pfeifer wrote:
> On Sat, 12 Sep 2009, Ryan Hill wrote:
> >> I haven't been able to bootstrap x86_64-unknown-linux-gnu at all since this
> >> started. Latest attempt was with r151649.
> >> Configured as:
> > I was able to build using --enable-checki
On Sat, 12 Sep 2009, Ryan Hill wrote:
>> I haven't been able to bootstrap x86_64-unknown-linux-gnu at all since this
>> started. Latest attempt was with r151649.
>> Configured as:
> I was able to build using --enable-checking. Should I file a new PR?
If you are still seeing this, I think that wou
On Fri, 11 Sep 2009 21:09:22 -0600
Ryan Hill wrote:
> I haven't been able to bootstrap x86_64-unknown-linux-gnu at all since this
> started. Latest attempt was with r151649.
> Configured as:
>
> /var/tmp/portage/sys-devel/gcc-4.5.0_pre/work/gcc-4.5.0-/configure
> --prefix=/usr --bindir=
1plus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> Bootstrap comparison failure!
> gcc/coverage.o differs
> gcc/gcov.o differs
> gcc/gcov-dump.o differs
> gmake[2]: *** [compare] Error 1
> gmake[2]: Leaving directory `/usr/nabil-files/pfeifer/OBJ-0909-2216'
;
"`echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=:"
"STAGE1_CFLAGS=-g -fkeep-inline-functions" "STAGE1_TFLAGS=" "STAGE2_CFLAGS=-g
-O2 -fomit-frame-pointer -gtoggle" "STAGE2_TFLAGS=" "STAGE3_CFLAGS=-g
>> I tried --save-temps and the resulting .s files were identical.
>> I found that the problem was introduced by "as".
>> I ran "as" twice with the same arguments. The two resulting .o files
>> were different.
>> I upgraded the binutils to the latest version: 2.19. The problem
>> hasn't gone away.
chenyang writes:
>> Try running your commands with the --save-temps options and compare the
>> resulting .s files. Also, try running the commands with the
>> -fdump-tree-all -fdump-rtl-all options and see where the dump files
>> first differ.
>>
> I tried --save-temps and the resulting .s files
Thanks, Ian,
> These kinds of issues are always difficult to debug. There have been a
> couple of patches to stabilize different sorts which I don't think are
> in 4.3.3. That could conceivably cause differences if address space
> randomization is turned on. I don't know of any specific bug rep
chenyang writes:
> I got a "Bootstrap comparison failure!" error when building gcc 4.3.3:
These kinds of issues are always difficult to debug. There have been a
couple of patches to stabilize different sorts which I don't think are
in 4.3.3. That could conceivably cause diff
Hi everyone,
I got a "Bootstrap comparison failure!" error when building gcc 4.3.3:
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap comparison failure!
./tree-cfg.o differs
./double-int.o differs
./gimple-low.o differs
./tree-
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1obj-checksum.o differs
warning: ./cc1objplus-checksum.o differs
warning: ./cc1plus-checksum.o differs
warning: ./libgcc/_chkstk.o differs
Bootstrap comparison failure!
./ada/exp_aggr.o differs
make[2]: *** [compare] Erro
For quite some time now, I've been getting bootstrap comparison
failures with trunk on sparc64/sparc linux
I kind of guess that they might be related to other big endian
bootstrap comparison failures. Would you benefit from me posting
something specific from my failures or do you suggest that
[EMAIL PROTECTED] wrote on 24/06/2007 01:17:34:
> > I tested it on powerpc64-linux with the default option
> > --with-cpu=default32.
>
> Ah, so this is a 32-bit compiler like on sparc64-linux?
--with-cpu=default32 means that the compiler itself and it's produced
code are 32 bits by default.
Re
> I tested it on powerpc64-linux with the default option
> --with-cpu=default32.
Ah, so this is a 32-bit compiler like on sparc64-linux?
--
Eric Botcazou
Eric Botcazou <[EMAIL PROTECTED]> wrote on 23/06/2007 21:50:57:
> > I'm going to try the 64-bit variant.
>
> SPARC/Solaris 64-bit is OK, as well as IA-64/Linux according to:
> http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg01044.html
>
> Do you test PowerPC 32-bit or should I try a build on
> I'm going to try the 64-bit variant.
SPARC/Solaris 64-bit is OK, as well as IA-64/Linux according to:
http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg01044.html
Do you test PowerPC 32-bit or should I try a build on Darwin or AIX?
--
Eric Botcazou
> Maybe the problem will arise on other platforms and we'll be able to debug
> it.
SPARC/Solaris 32-bit is OK. I'm going to try the 64-bit variant.
--
Eric Botcazou
Eric Botcazou <[EMAIL PROTECTED]> wrote on 21/06/2007 21:10:15:
> > I am now bootstrapping only c. If that will pass OK I can check Ada on
> > an older revision if you wish.
>
> I'm not sure that would really help in this case. The fact that x86 and
> x86-64 are both clean with structural alia
> I am now bootstrapping only c. If that will pass OK I can check Ada on
> an older revision if you wish.
I'm not sure that would really help in this case. The fact that x86 and
x86-64 are both clean with structural alias analysis would seem to show
that there is no fundamental bad interaction
> Note that if cc1-checksum.o differs, it likely means the issue is unrelated
> to Ada.
cc1-checksum.o very offen differs on my machine, it doesn't stop the build.
--
Eric Botcazou
> >
> > Which revision? The Ada compiler bootstraps fine on i586 and x86-64 at
> > revision 125912:125915M (i.e with structural alias analysis enabled).
>
> Note that if cc1-checksum.o differs, it likely means the issue is
unrelated to
> Ada.
I am now bootstrapping only c. If that will pass OK
> Which revision? The Ada compiler bootstraps fine on i586 and x86-64 at
> revision 125912:125915M (i.e with structural alias analysis enabled).
>
revision 125915.
Thanks,
Revital
2 and 3
> > warning: ./cc1-checksum.o differs
> > Bootstrap comparison failure!
> > ./ada/a-except.o differs
>
> Which revision? The Ada compiler bootstraps fine on i586 and x86-64 at
> revision 125912:125915M (i.e with structural alias analysis enabled).
Note that if cc1-checksum.o differs, it likely means the issue is unrelated to
Ada.
Arno
> I get the following bootstrap comparison failure on powerpc64
> for Ada (--enable-languages=ada) with BOOT_CFLAGS='-O2'.
>
> Revital
>
> make[2]: Entering directory `/home/revital/mainline_ccp/build'
> make[3]: Entering directory `/home/revital/mainline_ccp/b
Hello,
I get the following bootstrap comparison failure on powerpc64
for Ada (--enable-languages=ada) with BOOT_CFLAGS='-O2'.
Revital
make[2]: Entering directory `/home/revital/mainline_ccp/build'
make[3]: Entering directory `/home/revital/mainline_ccp/build'
rm -f
As I posted on http://gcc.gnu.org/ml/gcc/2007-05/msg00058.html, I
still have this problem for the released 4.2.0.
--
Cheers,
/ChJ
paring stages 2 and 3
warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs
Bootstrap comparison failure!
./attribs.o differs
./c-aux-info.o differs
./c-common.o differs
./c-convert.o differs
./c-cppbuiltin.o differs
./c-decl.o differs
./c-dump.o differs
./c-errors.o differs
./c-forma
c1obj-checksum.o differs
warning: ./cc1-checksum.o differs
Bootstrap comparison failure!
./ipa-inline.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/revitale/mainline_zero_mve/build'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/hom
On Mon, 2005-12-19 at 13:58, Daniel Jacobowitz wrote:
> > I suspect that if you run a bootstrap of gcc on Linux with
> > PWDCMD=/bin/pwd it will fail too.
>
> Yes, I saw a suggestion about this on IRC, but I tried it - it doesn't
> fail. The path that matters is not one ever returned by PWDCMD bu
On Mon, Dec 19, 2005 at 01:18:21PM +, Richard Earnshaw wrote:
> I think the problem is PWDCMD (defaults to pwd) in the top-level
> makefile. If your shell builds in pwd, then things will work. If it
> doesn't then you'll get /bin/pwd which gives the canonical path. Bash
> has a built-in pwd,
On Sun, 2005-12-18 at 16:49, Daniel Jacobowitz wrote:
> On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> > Looks like the new toplevel bootstrap infrastructure broke
> > bootstrapping on OpenBSD. I get a bootstrap comparison which is
> > caused by differences in the compilation dir
Paolo, what do you think?
I think I agree. After all when I added the "ln -s" support we did not
have anything remotely similar to the current logic for "make all",
"make unstage", "make stage".
Paolo
On Sun, Dec 18, 2005 at 07:49:13PM +0100, Mark Kettenis wrote:
> Heh, the shell does set PWD, but does not export it. If I explicitly
> say "export PWD", before "make bootstrap" it seems to work.
Weird.
> > I've been considering disabling ln -s support. It's too fragile,
> > though this is the
> Date: Sun, 18 Dec 2005 11:49:37 -0500
> From: Daniel Jacobowitz <[EMAIL PROTECTED]>
>
> On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> > Looks like the new toplevel bootstrap infrastructure broke
> > bootstrapping on OpenBSD. I get a bootstrap comparison which is
> > caused by
On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> Looks like the new toplevel bootstrap infrastructure broke
> bootstrapping on OpenBSD. I get a bootstrap comparison which is
> caused by differences in the compilation directory encoded in the
> object files from different stages.
>
Looks like the new toplevel bootstrap infrastructure broke
bootstrapping on OpenBSD. I get a bootstrap comparison which is
caused by differences in the compilation directory encoded in the
object files from different stages.
Forcing the coplevel configure to use "mv" instead of "ln -s" by setting
On Mon, Oct 10, 2005 at 11:58:04PM -0400, David Edelsohn wrote:
> >>>>> Albert Chin writes:
>
> Albert> I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a
> Albert> bootstrap comparison failure:
> Albert> $ CC=/usr/vac/bin/cc CONFIG_SHELL=
>>>>> Albert Chin writes:
Albert> I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a
Albert> bootstrap comparison failure:
Albert> $ CC=/usr/vac/bin/cc CONFIG_SHELL=/opt/fsw/bin/bash \
Albert> I don't see anything on
Albert> http://gcc.gnu.org/
I've built gcc-4.0.2 as follows on AIX 5.3 and am receiving a
bootstrap comparison failure:
$ cd /opt/build
$ bzip2 -dc gcc-4.0.2.tar.bz2 | tar xf -
$ mkdir gcc
$ cd gcc
$ CC=/usr/vac/bin/cc CONFIG_SHELL=/opt/fsw/bin/bash \
/opt/fsw/bin/bash /opt/build/gcc-4.0.2/configure \
-
62 matches
Mail list logo
