GCC 4.5.1 is being released, adjusting target milestone.

Please verify if 4.5.1 is still broken.

(In reply to comment #2)
> Please verify if 4.5.1 is still broken.

Still broken, and apparently still at the same place:

../gcc-4.5.1/configure && make bootstrap4-lean

------------------------------------------------
make[2]: Entering directory `/home/htl10/tmp-build/gcc-obj'
make[3]: Entering directory `/home/htl10/tmp-build/gcc-obj'
rm -f stage_current
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-obj'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/java/win32-host.o differs
gcc/build/min-insn-modes.o differs
gcc/dummy-checksum.o differs
gcc/insn-peep.o differs
gcc/graphite-blocking.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/graphite-dependences.o differs
gcc/graphite-interchange.o differs
gcc/graphite-poly.o differs
gcc/graphite-ppl.o differs
gcc/graphite-scop-detection.o differs
gcc/graphite-sese-to-poly.o differs
gcc/loop-doloop.o differs
gcc/version.o differs
gcc/vmsdbgout.o differs
gcc/xcoffout.o differs
gcc/host-default.o differs
gcc/gcc-options.o differs
gcc/collect2-aix.o differs
intl/osdep.o differs
libiberty/safe-ctype.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-obj'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-obj'
make: *** [bootstrap4-lean] Error 2
bash-2.05a# pwd
/home/htl10/tmp-build/gcc-obj
--------------------------------------

GCC 4.5.2 is being released, adjusting target milestone.

(In reply to comment #4)
> GCC 4.5.2 is being released, adjusting target milestone.

same problem with 4.5.2:

CONFIG_SHELL=/usr/local/bin/bash ../gcc-4.5.2/configure && CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/make
...
make[2]: Entering directory `/home/htl10/tmp-build/gcc-452-obj'
make[3]: Entering directory `/home/htl10/tmp-build/gcc-452-obj'
rm -f stage_current
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-452-obj'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/java/win32-host.o differs
gcc/build/min-insn-modes.o differs
gcc/dummy-checksum.o differs
gcc/insn-peep.o differs
gcc/graphite-blocking.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/graphite-dependences.o differs
gcc/graphite-interchange.o differs
gcc/graphite-poly.o differs
gcc/graphite-ppl.o differs
gcc/graphite-scop-detection.o differs
gcc/graphite-sese-to-poly.o differs
gcc/loop-doloop.o differs
gcc/version.o differs
gcc/vmsdbgout.o differs
gcc/xcoffout.o differs
gcc/host-default.o differs
gcc/gcc-options.o differs
gcc/collect2-aix.o differs
intl/osdep.o differs
libiberty/safe-ctype.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-452-obj'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-452-obj'
make: *** [all] Error 2
bash-2.05a#

GCC 4.5.3 is being released, adjusting target milestone.

4.6.0 also fails.

CONFIG_SHELL=/usr/local/bin/bash ../gcc-4.6.0/configure && CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/make
....

make[3]: Entering directory `/home/htl10/tmp-build/gcc-460-obj'
rm -f stage_current
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-460-obj'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/java/win32-host.o differs
gcc/build/version.o differs
gcc/build/min-insn-modes.o differs
gcc/c-lang.o differs
gcc/insn-peep.o differs
gcc/insn-enums.o differs
gcc/graphite-blocking.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/graphite-cloog-util.o differs
gcc/graphite-dependences.o differs
gcc/graphite-flattening.o differs
gcc/graphite-poly.o differs
gcc/graphite-interchange.o differs
gcc/graphite-ppl.o differs
gcc/graphite-scop-detection.o differs
gcc/graphite-sese-to-poly.o differs
gcc/hwint.o differs
gcc/loop-doloop.o differs
gcc/target-globals.o differs
gcc/version.o differs
gcc/vmsdbgout.o differs
gcc/xcoffout.o differs
gcc/collect2-aix.o differs
intl/osdep.o differs
libiberty/safe-ctype.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-460-obj'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-460-obj'
make: *** [all] Error 2

4.5.3 also fails the same way.

CONFIG_SHELL=/usr/local/bin/bash ../gcc-4.5.3/configure && CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/make
....

make[2]: Entering directory `/home/htl10/tmp-build/gcc-453-obj'
make[3]: Entering directory `/home/htl10/tmp-build/gcc-453-obj'
rm -f stage_current
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-453-obj'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/java/win32-host.o differs
gcc/build/min-insn-modes.o differs
gcc/dummy-checksum.o differs
gcc/insn-peep.o differs
gcc/graphite-blocking.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/graphite-dependences.o differs
gcc/graphite-interchange.o differs
gcc/graphite-poly.o differs
gcc/graphite-ppl.o differs
gcc/graphite-scop-detection.o differs
gcc/graphite-sese-to-poly.o differs
gcc/loop-doloop.o differs
gcc/version.o differs
gcc/vmsdbgout.o differs
gcc/xcoffout.o differs
gcc/gcc-options.o differs
gcc/collect2-aix.o differs
intl/osdep.o differs
libiberty/safe-ctype.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-453-obj'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-453-obj'
make: *** [all] Error 2

Please try a 4.6.1 tarball and *don't* use relative paths to configure/build in
a subdir of the source tree.  I bootstrap gcc (4.5 to 4.7) on Tru64 UNIX all the
time and never saw this problem.

> Please try a 4.6.1 tarball and *don't* use relative paths to configure/build in
> a subdir of the source tree.  I bootstrap gcc (4.5 to 4.7) on Tru64 UNIX all
> the time and never saw this problem.

Not a subdir -  a parallel directory.

source is at  /home/htl10/tmp-build/gcc-4.5.1
obj dir is at /home/htl10/tmp-build/gcc-451-dir

> Not a subdir -  a parallel directory.
>
> source is at  /home/htl10/tmp-build/gcc-4.5.1
> obj dir is at /home/htl10/tmp-build/gcc-451-dir

Did you use an absolute path for the source dir?  There have been
problems with relative paths in the past.

	Rainer

(In reply to comment #11)
> Did you use an absolute path for the source dir?  There have been
> problems with relative paths in the past.

Tried absolute path with 4.6.1, and compilation finishes alright.

cd /home/htl10/tmp-build
tar jxpvf ../sources/www.mirrorservice.org/sites/sourceware.org/pub/gcc/releases/gcc-4.6.1/gcc-4.6.1.tar.bz2
mkdir gcc-461-obj
cd gcc-461-obj
CONFIG_SHELL=/usr/local/bin/bash /home/htl10/tmp-build/gcc-4.6.1/configure && CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/make

---------------

I am running make -k check at the moment but will retry 4.5.3/4.6.0 afterwards. Note that 4.4.6 fails even with absolute path at a later place.
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947#c14)

So I can probably say this bug was fixed with 4.6.1.

adding 4.6.1 known to work. pending retrying 4.5.3/4.6.0

Retry 4.5.3 with absolute paths, and still fails; so I won't bother with 4.6.0 (likely as it was, fails). So it looks like it was a genuine regression in 4.5.x that was fixed some how with 4.6.1 .

CONFIG_SHELL=/usr/local/bin/bash /home/htl10/tmp-build/gcc-4.5.3/configure && CONFIG_SHELL=/usr/local/bin/bash /usr/local/bin/make

----------------------------
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-453-obj'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/java/win32-host.o differs
gcc/build/min-insn-modes.o differs
gcc/dummy-checksum.o differs
gcc/insn-peep.o differs
gcc/graphite-blocking.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/graphite-dependences.o differs
gcc/graphite-interchange.o differs
gcc/graphite-poly.o differs
gcc/graphite-ppl.o differs
gcc/graphite-scop-detection.o differs
gcc/graphite-sese-to-poly.o differs
gcc/loop-doloop.o differs
gcc/version.o differs
gcc/vmsdbgout.o differs
gcc/xcoffout.o differs
gcc/gcc-options.o differs
gcc/collect2-aix.o differs
intl/osdep.o differs
libiberty/safe-ctype.o differs
make[2]: *** [compare] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-453-obj'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-453-obj'
make: *** [all] Error 2
-------------------------------

/home/htl10/tmp-build/gcc-4.6.2-build'
Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/java/win32-host.o differs
gcc/build/version.o differs
gcc/build/min-insn-modes.o differs
gcc/c-lang.o differs
gcc/insn-peep.o differs
gcc/insn-enums.o differs
gcc/graphite-blocking.o differs
gcc/graphite-clast-to-gimple.o differs
gcc/graphite-cloog-util.o differs
gcc/graphite-dependences.o differs
gcc/graphite-flattening.o differs
gcc/graphite-poly.o differs
gcc/graphite-interchange.o differs
gcc/graphite-ppl.o differs
gcc/graphite-scop-detection.o differs
gcc/graphite-sese-to-poly.o differs
gcc/hwint.o differs
gcc/loop-doloop.o differs
gcc/target-globals.o differs
gcc/version.o differs
gcc/vmsdbgout.o differs
gcc/xcoffout.o differs
gcc/collect2-aix.o differs
intl/osdep.o differs
libiberty/safe-ctype.o differs

File sizes seems crazy:

# ls -l */cc*-checksum.o
-rw-r--r--   1 root     system       592 May  7 02:38 stage2-gcc/cc1-checksum.o
-rw-r--r--   1 root     system       600 May  7 03:07 stage2-gcc/cc1obj-checksum.o
-rw-r--r--   1 root     system       600 May  7 02:49 stage2-gcc/cc1plus-checksum.o
-rw-r--r--   1 root     system     22928 May  7 03:33 stage3-gcc/cc1-checksum.o
-rw-r--r--   1 root     system     22928 May  7 03:40 stage3-gcc/cc1obj-checksum.o
-rw-r--r--   1 root     system     22936 May  7 03:36 stage3-gcc/cc1plus-checksum.o

Failed with 4.6.3 (in addition to 4.6.2).

ls -l */cc*-checksum.o
-rw-r--r--   1 root     system       592 May  7 10:05 stage2-gcc/cc1-checksum.o
-rw-r--r--   1 root     system       600 May  7 10:33 stage2-gcc/cc1obj-checksum.o
-rw-r--r--   1 root     system       600 May  7 10:16 stage2-gcc/cc1plus-checksum.o
-rw-r--r--   1 root     system     22928 May  7 10:59 stage3-gcc/cc1-checksum.o
-rw-r--r--   1 root     system     22928 May  7 11:07 stage3-gcc/cc1obj-checksum.o
-rw-r--r--   1 root     system     22936 May  7 11:02 stage3-gcc/cc1plus-checksum.o

Time to go back to 4.6.1 and see...

While the checksum files are expected to differ (thus there are only
warnings about them), the size increase looks really strange: in my
current 4.6.4 build on alpha-dec-osf5.1b I have

-rw-r--r-- 1 ro gcc 22944 May  6 05:01 gcc/cc1-checksum.o
-rw-r--r-- 1 ro gcc 22944 May  6 03:38 prev-gcc/cc1-checksum.o
-rw-r--r-- 1 ro gcc 28504 May  5 23:58 stage1-gcc/cc1-checksum.o

Could you please attach the one smallest of the non *-checksum.o
differing files from all 3 stages for investigation?

Thanks.
	Rainer

Created attachment 27346 [details]
one set of those checksum files. tar.gz'ed

I think this one is from 4.6.1, make bootstrap4-lean

Created attachment 27347 [details]
another set of those checksum files. tar.gz'ed

I think this one is from make bootstrap4

Created attachment 27348 [details]
3rd set of those checksum files. tar.gz'ed

This one is from 4.6.2 (the other two from 4.6.1), just plain make.

There are two curious things:
1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is normal).

2. I did have a success with 4.6.1 (and I believe with both make/make bootstrap4 or 4-lean) a while ago, therefore I closed the bug. I did not install 4.6.1 at the time but stayed at 4.3.3 (mostly to test and verify the other issues), but now I cannot build 4.6.1 correctly again. The system has not been changed much since then, the only changes I can think of which is relevant is that I installed updated versions of the gcc dependencies (mpfr-3.1.0,mpc-0.9,gmp-5.0.5)
from the most updated versions the last time I looked at gcc.

> --- Comment #21 from Hin-Tak Leung <htl10 at users dot sourceforge.net> 2012-05-08 14:15:52 UTC ---

I think there was a misunderstanding: I specificially asked for the
smallest of the differing .o files *other than cc1*-checksum.o* since
the latter are expected to differ between stages.  But for the moment, I
think we can do with cc1-checksum.o alone.

> There are two curious things:
> 1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is
> normal).

That's certainly completely unexpected.  I'd ask you to rebuild
cc1-checksum.o for stage2 and stage3 (move the .o's aside, run make -n
cc1-checksum.o, then manually add -v -save-temps to the compilation
line.  Then attach a tarball with the .c and output files and the gcc -v
output to see if there are any obvious diffences between the compilations.

> 2. I did have a success with 4.6.1 (and I believe with both make/make
> bootstrap4 or 4-lean) a while ago, therefore I closed the bug. I did not

Please always try this with a plain make/make bootstrap.  I don't
currently want to debug issues which might be caused by non-default
targets.  I don't see why they should be, but please let us stay with
the basics.

> install 4.6.1 at the time but stayed at 4.3.3 (mostly to test and verify the
> other issues), but now I cannot build 4.6.1 correctly again. The system has not
> been changed much since then, the only changes I can think of which is relevant
> is that I installed updated versions of the gcc dependencies
> (mpfr-3.1.0,mpc-0.9,gmp-5.0.5)
> from the most updated versions the last time I looked at gcc.

This is certainly a problem: the installation guide states

   Several support libraries are necessary to build GCC, some are required,
   others optional. While any sufficiently new version of required tools
   usually work, library requirements are generally stricter. Newer
   versions may work in some cases, but it's safer to use the exact
   versions documented. We appreciate bug reports about problems with newer
   versions, though.

The sentence about newer versions is there for a reason.  In fact, on
Tru64 UNIX the situation is even worse: gmp 4.3.2 make check fails for
me, so I'm currently staying with gmp 4.2.1, mpfr 2.3.2, and mpc 0.8.

Before using *any* version of gmp/mpfr/mpc with gcc (or for any other
purpose), make sure that they pass make check, as prominently stated in
e.g. the gmp announcements.

	Rainer

(In reply to comment #22)
> > --- Comment #21 from Hin-Tak Leung <htl10 at users dot sourceforge.net> 2012-05-08 14:15:52 UTC ---
> 
> I think there was a misunderstanding: I specificially asked for the
> smallest of the differing .o files *other than cc1*-checksum.o* since
> the latter are expected to differ between stages.  But for the moment, I
> think we can do with cc1-checksum.o alone.

Okay, sorry about that.

> > There are two curious things:
> > 1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is
> > normal).
> 
> That's certainly completely unexpected.  I'd ask you to rebuild
> cc1-checksum.o for stage2 and stage3 (move the .o's aside, run make -n
> cc1-checksum.o, then manually add -v -save-temps to the compilation
> line.  Then attach a tarball with the .c and output files and the gcc -v
> output to see if there are any obvious diffences between the compilations.

I'll get round to it when I find some time to do so, soon.

> > 2. I did have a success with 4.6.1 (and I believe with both make/make
> > bootstrap4 or 4-lean) a while ago, therefore I closed the bug. I did not
> 
> Please always try this with a plain make/make bootstrap.  I don't
> currently want to debug issues which might be caused by non-default
> targets.  I don't see why they should be, but please let us stay with
> the basics.

Out of the three attachments, one is with plain make, the other two, one with bootstrap4 and bootstrap4-lean. (I think I tried them in the order of 4-lean, 4, plain - so you could see which is which from the time stamp). I know what you are saying, that's why I tried it simplier and simpler :-(.

> > install 4.6.1 at the time but stayed at 4.3.3 (mostly to test and verify the
> > other issues), but now I cannot build 4.6.1 correctly again. The system has not
> > been changed much since then, the only changes I can think of which is relevant
> > is that I installed updated versions of the gcc dependencies
> > (mpfr-3.1.0,mpc-0.9,gmp-5.0.5)
> > from the most updated versions the last time I looked at gcc.
> 
> This is certainly a problem: the installation guide states
> 
>    Several support libraries are necessary to build GCC, some are required,
>    others optional. While any sufficiently new version of required tools
>    usually work, library requirements are generally stricter. Newer
>    versions may work in some cases, but it's safer to use the exact
>    versions documented. We appreciate bug reports about problems with newer
>    versions, though.
> 
> The sentence about newer versions is there for a reason.  In fact, on
> Tru64 UNIX the situation is even worse: gmp 4.3.2 make check fails for
> me, so I'm currently staying with gmp 4.2.1, mpfr 2.3.2, and mpc 0.8.
> 
> Before using *any* version of gmp/mpfr/mpc with gcc (or for any other
> purpose), make sure that they pass make check, as prominently stated in
> e.g. the gmp announcements.
> 
>     Rainer

Argh :-(. I did run make check on one of them (gmp?) because it says so at the end of make or 'make install', and it finished okay.

I can certainly go back - if it is worthwhile. I'll try to re-do the checksum object files first.

Can you check 4.7.0/4.7.1 please?

Created attachment 28106 [details]
stage*-gcc/c-lang.o -  tgz'ed

stage*-gcc/c-lang.o

-rw-r--r-- root/system  533880 2012-08-30 10:28 stage1-gcc/c-lang.o
-rw-r--r-- root/system   12112 2012-08-30 11:18 stage2-gcc/c-lang.o
-rw-r--r-- root/system  176168 2012-08-30 13:18 stage3-gcc/c-lang.o

(In reply to comment #22)
<snipped>
> The sentence about newer versions is there for a reason.  In fact, on
> Tru64 UNIX the situation is even worse: gmp 4.3.2 make check fails for
> me, so I'm currently staying with gmp 4.2.1, mpfr 2.3.2, and mpc 0.8.
> 
> Before using *any* version of gmp/mpfr/mpc with gcc (or for any other
> purpose), make sure that they pass make check, as prominently stated in
> e.g. the gmp announcements.
> 
>     Rainer

You are quite right about that - 'make check' is okay for me for gmp 4.x and 5.x, but mpfr 3.1.x fails (3.0.x and 2.4.x okay), mpc 0.8 & 1.0 are okay *if* mpfr is reverted back to 3.0.x .

So I have wiped the faulty libraries, make check the older versions and only install if pass; but the stage compare still fails between 2 and 3 with just plain "make" (attached).

I am currently retrying with make bootstrap4-lean - I know I have finished 4.6.1 correctly *once*, I just don't know how :-(.

FWIW, I just filed the MFPR 3.1.x "make check" issue:

https://gforge.inria.fr/tracker/index.php?func=detail&aid=14806&group_id=136&atid=619

(In reply to comment #22)

> > There are two curious things:
> > 1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is
> > normal).
> 
> That's certainly completely unexpected.  I'd ask you to rebuild
> cc1-checksum.o for stage2 and stage3 (move the .o's aside, run make -n
> cc1-checksum.o, then manually add -v -save-temps to the compilation
> line.  Then attach a tarball with the .c and output files and the gcc -v
> output to see if there are any obvious diffences between the compilations.

*.c is the same - the difference in size comes from -gtoggle (added to stage 2).

Created attachment 28115 [details]
sets of failed-to-compare objs from 4.7.1

tgz'ed, failed-to-compared obj's from 4.7.1 .

stage2 always a lot smaller. I think it is from -gtoggle. Elsewhere there are a few other bugs from this switch for other unusual architectures.

I commented out gcc-4.7.1/config/bootstrap-debug.mk :

#STAGE2_CFLAGS += -gtoggle

and 4.7.1 passed.

this seems likely the cause - -gtoogle was introduced in 4.5.x. I am going to try going backwards to see whether this will have the older versions pass.

Two curiosity:
- how did I get 4.6.1 to pass, once?
- why Rainer's system isn't similiarly affected?

I don't think bootstrap-debug.mk cannot be used for alpha OSF.

configure checks to see if it is possible:
    if echo "int f (void) { return 0; }" > conftest.c &&
       ${CC} -c conftest.c &&
       mv conftest.o conftest.o.g0 &&
       ${CC} -c -g conftest.c &&
       mv conftest.o conftest.o.g &&
       ${srcdir}/contrib/compare-debug conftest.o.g0 conftest.o.g > /dev/null 2>&1; then
      :

But this uses the original compiler and not GCC to do the test.
You should be able to do --without-build-config .

Went back to 4.5.0 and commenting out '#STAGE2_CFLAGS += -gtoggle' in config/bootstrap-debug.mk have it going beyond stage2/3 comparison. So I don't know how I managed to build 4.6.1 once (http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00587.html).

I'll just go back and try every one of them with that mod, and run 'make -k check' afterwards.

"-gtoggle" seems to do more than just toggling -g - after strip'ing, the objects still differ by an extra text section in one of them. (anybody can have a look at the attached tarballs of object files in this report).

> --- Comment #26 from Hin-Tak Leung <htl10 at users dot sourceforge.net>
> 2012-08-30 14:19:16 UTC ---
> (In reply to comment #22)
> <snipped>
>> The sentence about newer versions is there for a reason.  In fact, on
>> Tru64 UNIX the situation is even worse: gmp 4.3.2 make check fails for
>> me, so I'm currently staying with gmp 4.2.1, mpfr 2.3.2, and mpc 0.8.
>> 
>> Before using *any* version of gmp/mpfr/mpc with gcc (or for any other
>> purpose), make sure that they pass make check, as prominently stated in
>> e.g. the gmp announcements.
>> 
>>     Rainer
>
> You are quite right about that - 'make check' is okay for me for gmp 4.x and
> 5.x, but mpfr 3.1.x fails (3.0.x and 2.4.x okay), mpc 0.8 & 1.0 are okay *if*
> mpfr is reverted back to 3.0.x .

I've no idea why gmp 4.3.x or 5.x works for you: both fail make check
for me if built with gcc 4.4.2.  I've not yet tried newer versions.

	Rainer

> --- Comment #27 from Hin-Tak Leung <htl10 at users dot sourceforge.net>
> 2012-08-30 14:56:46 UTC ---
> FWIW, I just filed the MFPR 3.1.x "make check" issue:
>
> https://gforge.inria.fr/tracker/index.php?func=detail&aid=14806&group_id=136&atid=619

Thanks for doing this.  I might retry gmp 3.1.1 with current gcc since
at least one TLS bug was fixed there.

I didn't bother checking mpfr once I noticed that even current gmp
versions don't work correctly.

	Rainer

> --- Comment #28 from Hin-Tak Leung <htl10 at users dot sourceforge.net>
> 2012-08-30 17:32:35 UTC ---
> (In reply to comment #22)
>
>> > There are two curious things:
>> > 1. why does the 2nd stage drops to only about 600 byte. (I assume 20-30k is
>> > normal).
>> 
>> That's certainly completely unexpected.  I'd ask you to rebuild
>> cc1-checksum.o for stage2 and stage3 (move the .o's aside, run make -n
>> cc1-checksum.o, then manually add -v -save-temps to the compilation
>> line.  Then attach a tarball with the .c and output files and the gcc -v
>> output to see if there are any obvious diffences between the compilations.
>
> *.c is the same - the difference in size comes from -gtoggle (added to stage
> 2).

You never mentioned -gtoggle before.  It seems you are using
--with-build-config=bootstrap-debug, correct?  If you report a problem,
*please* provide *all* the necessary information about your build, which
includes exact configure options used.

Instead of retrying with each and every gcc release, it's much more
useful to stay with a single one that fails and investigate that in
detail.  Unfortunately, you never provided the exact command lines used
to build the differing stage2 and 3 object files I've requested some
time ago.  This way, the difference would have been immediately
obvious instead of running in circles for weeks.

	Rainer

> --- Comment #30 from Hin-Tak Leung <htl10 at users dot sourceforge.net>
> 2012-09-01 08:18:06 UTC ---
> I commented out gcc-4.7.1/config/bootstrap-debug.mk :
>
> #STAGE2_CFLAGS += -gtoggle
>
> and 4.7.1 passed.
>
> this seems likely the cause - -gtoogle was introduced in 4.5.x. I am going to
> try going backwards to see whether this will have the older versions pass.

config/bootstrap-debug.mk isn't used by default, you need to enable it
with --with-build-config.

> Two curiosity:
> - how did I get 4.6.1 to pass, once?

No idea, perhaps you `forgot' to enable bootstrap-debug.mk?

> - why Rainer's system isn't similiarly affected?

Because I'm using default configure options as far as possible, as I had
suggested to you several times: start with the basics and if this works,
continue from there.

	Rainer

> --- Comment #32 from Hin-Tak Leung <htl10 at users dot sourceforge.net>
> 2012-09-01 11:22:55 UTC ---
> Went back to 4.5.0 and commenting out '#STAGE2_CFLAGS += -gtoggle' in
> config/bootstrap-debug.mk have it going beyond stage2/3 comparison. So I don't
> know how I managed to build 4.6.1 once
> (http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00587.html).
>
> I'll just go back and try every one of them with that mod, and run 'make -k
> check' afterwards.

Please forget about gcc 4.5.x: I don't test that branch any longer, so
even if you find something useful, it's almost guaranteed that I won't
touch that branch.

> "-gtoggle" seems to do more than just toggling -g - after strip'ing, the
> objects still differ by an extra text section in one of them. (anybody can have
> a look at the attached tarballs of object files in this report).

If you had mentioned -gtoggle previously, you'd have saved all of us a
long useless hunt: different object files with and without -gtoggle can
easily be reproduced with a trivial source file.

I'll try to have a look what's going on.

	Rainer

(In reply to comment #33)
> I've no idea why gmp 4.3.x or 5.x works for you: both fail make check
> for me if built with gcc 4.4.2.  I've not yet tried newer versions.

probably slightly different cpu/system - you have a alphaev67-dec-osf5.1b or something else instead of alphaev68-dec-osf5.1a, I believe? That probably also explains the slight difference with gmp. 

BTW, the mfpr author closed the mfpr bug report as 'not his problem', because he had documented that TLS does not work on 'some systems'. Maybe this should be added to the platform-specific section of gcc's build docs?

(In reply to comment #36)
> config/bootstrap-debug.mk isn't used by default, you need to enable it
> with --with-build-config.

I have not don't anything special - just plain configure . it is the default, and -gtoggle was newly added to 4.5.x . It is possible that I might have accidentally set CFLAGS or something, in which case it would by-pass that and use config/bootstrap-O1.mk , etc, I seem to read from the docs.

(In reply to comment #37)
> If you had mentioned -gtoggle previously, you'd have saved all of us a
> long useless hunt: different object files with and without -gtoggle can
> easily be reproduced with a trivial source file.

1. you advice did not work - moving the object files aside and re-run make does not regenerate the earlier stage object file.

2. it is a remote system behind a firewall and I had not been saving the "make" output, until they changed the remote-login time-outs and made me do 'nohup make &' instead.

3. As I wrote, -gtoggle was added and enabled in 4.5.x+ new. I looked elsewhere, it appeared that it also broke Mac OS X bootstrap briefly also - but of course, that's a far-more common system and got fixed right away... If I knew what to look for, of course I'd have written earlier. the benefit of hind-sight.

Anyway, I have re-run all(?) of 4.4+ wit 'configure && make', and a few selected ones with 'configure && make bootstrap4-lean' (it takes about 5-6 hours for that, and down to about 2 with -j3), but 'make -k check' takes longer (9-10 hours and -jX runs in never-ending circles, it appears). There are minor differences in some cases - about 3 tests. I'll post them to the testsuite mailing list to be archived eventually.

Can this be reproduced with 4.7.3, 4.8.0 or trunk?

> --- Comment #39 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-04-12 16:13:20 UTC ---
> Can this be reproduced with 4.7.3, 4.8.0 or trunk?

At most on the 4.7 branch: the Tru64 UNIX port was obsoleted in 4.7 and
removed in 4.8.

That said, I've no idea how BUILD_CONFIG would end up as bootstrap-debug
on Tru64 UNIX.  Even compiling the same source file twice produces
object files that aren't identical.  That's the reason config.log has

gcc_cv_prog_cmp_skip='cmp --ignore-initial=16 $$f1 $$f2'

if GNU cmp is installed.  compare-debug doesn't take this into account,
so if I manually run this code snippet from configure

    if echo "int f (void) { return 0; }" > conftest.c &&
       ${CC} -c conftest.c &&
       mv conftest.o conftest.o.g0 &&
       ${CC} -c -g conftest.c &&
       mv conftest.o conftest.o.g &&
       ${srcdir}/contrib/compare-debug conftest.o.g0 conftest.o.g
    then
      echo bootstrap-debug
    else
      echo none
    fi

with CC and srcdir set appropriately, I get none for CC=gcc-4.4 and CC=cc.

Please try this on your system and tell us how you end up with
bootstrap-debug instead of none.

	Rainer

Closing as won't fix since Tru64 UNIX has since been removed.

(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
<snipped>
> if GNU cmp is installed.  compare-debug doesn't take this into account,
> so if I manually run this code snippet from configure
> 
>     if echo "int f (void) { return 0; }" > conftest.c &&
>        ${CC} -c conftest.c &&
>        mv conftest.o conftest.o.g0 &&
>        ${CC} -c -g conftest.c &&
>        mv conftest.o conftest.o.g &&
>        ${srcdir}/contrib/compare-debug conftest.o.g0 conftest.o.g
>     then
>       echo bootstrap-debug
>     else
>       echo none
>     fi
> 
> with CC and srcdir set appropriately, I get none for CC=gcc-4.4 and CC=cc.
> 
> Please try this on your system and tell us how you end up with
> bootstrap-debug instead of none.
<snipped>

I did export CC="gcc" and srcdir="/home/htl10/tmp-build/gcc-4.6.4" and cut and paste the above code interactively into the console, and found that it was prompting me for overwriting:

overwrite conftest.o.g0?
overwrite conftest.o.g?

(obviously that depends on configure being re-run twice, or doing it in a directory previously had configure run once). Does configure re-run itself?

Anyway, if this is the problem, this probably explain how I managed to build 4.6.1 once. My user account doesn't have a bashrc, but the root account alias mv to:

----------
mv () {
command mv -i $@;
}
----------

(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
> Please try this on your system and tell us how you end up with
> bootstrap-debug instead of none.

Hmm, sorry, redherring. I think I found the difference - it depends on which strip I am using - the one in /usr/local/bin/ gives bootstrap-debug, while the one in /sbin/ gives none. (problem of having some GNU variety of utilities in /usr/local/bin, and whethe that's in front of $PATH).

> --- Comment #43 from Hin-Tak Leung <htl10 at users dot sourceforge.net> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #40)
>> Please try this on your system and tell us how you end up with
>> bootstrap-debug instead of none.
>
> Hmm, sorry, redherring. I think I found the difference - it depends on which
> strip I am using - the one in /usr/local/bin/ gives bootstrap-debug, while the
> one in /sbin/ gives none. (problem of having some GNU variety of utilities in
> /usr/local/bin, and whethe that's in front of $PATH).

Makes sense: binutils support for Tru64 UNIX is known to be harmful (as
you just discovered) or broken (gas cannot even assemble hello world
compiler output), so nobody else every even tried binutils or parts
thereof.

Given that GCC 4.7 is the last release to support Tru64 UNIX, the
release branch will soon be closed with the advent of GCC 4.9, and
you're the only one ever to report this issue, I'll leave the bug as
WONTFIX.

Thanks for your detective work.

	Rainer