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
>> ---
>>
>> This is with --disable-checking. Leaving disable-c
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, the
> bootstrap completes succesful
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
[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
> > make[2]: Entering directory `/home/revital/mainline_ccp/build'
> > make[3]: Entering directory `/home/revital/mainline_ccp/build'
> > rm -f stage_current
> > make[3]: Leaving directory `/home/revital/mainline_ccp/build'
> > Comparing stages 2 and 3
> > warning: ./cc1-checksum.o differs
> > Boot
> 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 stage_current
> make[3]
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.
>
24 matches
Mail list logo
