[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

  Attachment #27346|0   |1
is obsolete||
  Attachment #27347|0   |1
is obsolete||
  Attachment #27348|0   |1
is obsolete||

--- Comment #25 from Hin-Tak Leung  
2012-08-30 14:04:53 UTC ---
Created attachment 28106
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28106
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

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #26 from Hin-Tak Leung  
2012-08-30 14:19:16 UTC ---
(In reply to comment #22)

> 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 :-(.

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #27 from Hin-Tak Leung  
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

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #28 from Hin-Tak Leung  
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).

[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251

Hin-Tak Leung  changed:

   What|Removed |Added

 CC||htl10 at users dot
   ||sourceforge.net

--- Comment #9 from Hin-Tak Leung  
2012-08-30 17:54:25 UTC ---
Thread issue? 
Many of the newer mpfr make check also takes a long time/time out if it is left
to the default tls enabled:

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

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #29 from Hin-Tak Leung  
2012-09-01 02:53:00 UTC ---
Created attachment 28115
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28115
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.

[Bug bootstrap/54447] New: gmp in source does not work on alphaev68-dec-osf5.1a

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54447

 Bug #: 54447
   Summary: gmp in source does not work on alphaev68-dec-osf5.1a
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ht...@users.sourceforge.net


In the course of looking at bug 44959, I tried building gcc 4.6.1 with an
in-source sub-directory of gmp/mpfr/mpc, and encountered strange errors:

In file included from fib_table.c:4:0:
/home/htl10/tmp-build/gcc-4.6.1-build/../gcc-4.6.1/gmp/gmp-impl.h:187:1: error:
unknown type name 'uint_least32_t'
make[5]: *** [fib_table.lo] Error 1
make[5]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp/mpn'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp'
make[2]: *** [all-stage2-gmp] Error 2
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build'
make: *** [all] Error 2

/home/htl10/tmp-build/gcc-4.6.1-build/../gcc-4.6.1/gmp/printf/doprnt.c: In
function '__gmp_doprnt':
/home/htl10/tmp-build/gcc-4.6.1-build/../gcc-4.6.1/gmp/printf/doprnt.c:273:8:
error: unknown type name 'intmax_t'
/home/htl10/tmp-build/gcc-4.6.1-build/../gcc-4.6.1/gmp/printf/doprnt.c:273:8:
internal compiler error: tree check: expected class 'type', 
have 'exceptional' (error_mark) in build_c_cast, at c-typeck.c:4541
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[5]: *** [doprnt.lo] Error 1
make[5]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp/printf'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build/gmp'
make[2]: *** [all-stage2-gmp] Error 2
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-4.6.1-build'
make: *** [all] Error 2


I tried working around the above errors as follows:

--- gmp-impl.h~2012-08-30 05:51:36.0 +0100
+++ gmp-impl.h2012-08-30 06:07:00.0 +0100
@@ -184,6 +184,8 @@


 /* gmp_uint_least32_t is an unsigned integer type with at least 32 bits. */
+#undef HAVE_UINT_LEAST32_T
+#undef HAVE_INTMAX_T
 #if HAVE_UINT_LEAST32_T
 typedef uint_least32_t  gmp_uint_least32_t;
 #else

--- vasprintf.c~2010-06-10 12:00:14.0 +0100
+++ vasprintf.c2012-08-30 06:15:36.0 +0100
@@ -52,6 +52,10 @@
 #include  /* for ptrdiff_t */
 #endif

+#ifndef SIZE_MAX
+#define SIZE_MAX (18446744073709551615UL)
+#endif
+
 #if HAVE_INTTYPES_H
 # include  /* for intmax_t */
 #else


the result still does not compare (bug likely due to other problems detailed in
44959). Anyhow, I suspect that the reasons for the above errors is that stage 1
uses system headers which do not have those C99(?) defines, but stage2 have
gcc's own patched headers, which have those defines, and therefore have those
config's during configure, but when it comes to actually compiling, still uses
the system headers, and therefore fails. These are my guesses.

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #30 from Hin-Tak Leung  
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.

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

[Bug libstdc++/54448] New: many failures with /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54448

 Bug #: 54448
   Summary: many failures with /sbin/loader: Error:
libstdc++.so.6: symbol "__pthread_mutex_init"
unresolved
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ht...@users.sourceforge.net


Am running 4.7.1 testsuite on alphaev68-dec-osf5.1a,
and seeing a lot of 

237556:./what-1.exe: /sbin/loader: Error: libstdc++.so.6: symbol
"__pthread_mutex_init" unresolved
237556:./what-1.exe: /sbin/loader: Fatal Error: Load of "./what-1.exe" failed:
Unresolved symbol name
FAIL: 27_io/ios_base/failure/what-1.cc execution test

about __pthread_mutex_init being unresolved.

The previous testsuite result I summitted
(http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00587.html) also seems to
have a lot of unexpected failures for 4.6.1:

=== libstdc++ Summary ===

# of expected passes4091
# of unexpected failures2312
# of expected failures80
# of unsupported tests747
=== g++ tests ===

I'll write again when 4.7.1. finishes.

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #32 from Hin-Tak Leung  
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.

"-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).

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

--- Comment #19 from Hin-Tak Leung  
2012-09-01 14:31:40 UTC ---
(In reply to comment #18)
> 4.4.6 fails, 4.5.x fails earlier in a different Bug 44959 ; 4.6.1 works so
> closing.

After editing config/bootstrap-debug.mk as in (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959#c32), 4.5.0 fails with this.

Am going to try every version of gcc in 4.5.x and 4.6.x and see when was it
fixed...

[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54448

Hin-Tak Leung  changed:

   What|Removed |Added

   Host||alphaev68-dec-osf5.1a
  Known to fail||4.6.1, 4.7.1

--- Comment #1 from Hin-Tak Leung  
2012-09-02 17:50:41 UTC ---
4.7.1 also have a high failure rate:

=== libstdc++ Summary ===

# of expected passes4583
# of unexpected failures2519
# of expected failures41
# of unsupported tests670

I have a few others and they are similar - about 1/2 failed in libstdc++ .

[Bug bootstrap/40894] [4.4/4.5/4.6/4.7 Regression] bootstrap4-lean failed crtfastmath.o comparision

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||4.7.1
  Known to fail||4.4.7

--- Comment #13 from Hin-Tak Leung  
2012-09-10 16:07:49 UTC ---
re-testing due to doubts about
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959#c30 - caveat STAGE2_CFLAGS,
bootstrap4-lean goes beyond crtfastmath.o comparision for 4.7.1 , fails for
4.4.7, okay for 4.3.3 (fails later for libjava bug 40947) and okay for 4.6.1.

[Bug bootstrap/40894] [4.4/4.5/4.6/4.7 Regression] bootstrap4-lean failed crtfastmath.o comparision

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||4.3.6

--- Comment #14 from Hin-Tak Leung  
2012-09-10 16:16:21 UTC ---
4.3.6 also okay.

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work|4.3.3   |4.6.0, 4.6.2, 4.6.3, 4.7.0,
   ||4.7.1
  Known to fail||4.3.3, 4.3.6, 4.4.7, 4.5.1,
   ||4.5.2, 4.5.3, 4.5.4

--- Comment #20 from Hin-Tak Leung  
2012-09-10 16:27:57 UTC ---
re-test everything, somehow 4.3.3 fails - it would appear that I upgraded
libtool and thing got broken; in any case, 4.6.x and 4.7.x works, and 4.5.x
fails; and 4.4.7 fails. Hmm, I should re-try 4.4.1 to be sure.

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work|4.4.1   |
  Known to fail||4.4.1

--- Comment #21 from Hin-Tak Leung  
2012-09-10 21:20:17 UTC ---
re-test and 4.4.1 fails.

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #38 from Hin-Tak Leung  
2012-09-14 14:43:00 UTC ---
(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.

[Bug testsuite/54697] New: testsuite in gcc 4.7.x leaves zombie processes.

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54697



 Bug #: 54697

   Summary: testsuite in gcc 4.7.x leaves zombie processes.

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: testsuite

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ht...@users.sourceforge.net





After trying to systematically re-test recent version of gcc on

alphaev68-dec-osf5.1a for other issues, I see a fair number of zombie processes

from 4.7.x:



(I was testing all versions from 4.3.x onwards, so only 4.7.x. leaves zombie

processes behind)



 14360 ??   T0:00.42

/home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/gcc/atomic-other-int.exe

163379 ??   T0:00.37

/home/htl10/tmp-build/gcc-4.7.2-build4/gcc/testsuite/gcc/atomic-other-longlong.exe

 19924 ??   T0:00.22

/home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/gcc/atomic-other-longlong.exe

212548 ??   T0:00.15

/home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/g++/bitfields-4.exe

 23369 ??   T0:00.81

/home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/gcc/atomic-other-short.exe

271603 ??   T0:00.38

/home/htl10/tmp-build/gcc-4.7.0-build/gcc/testsuite/gcc/atomic-other-int.exe

272885 ??   T0:00.28

/home/htl10/tmp-build/gcc-4.7.0-build/gcc/testsuite/gcc/atomic-other-int.exe

280126 ??   T0:00.69

/home/htl10/tmp-build/gcc-4.7.0-build/gcc/testsuite/gcc/atomic-other-short.exe

377160 ??   T0:00.39

/home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/gcc/atomic-other-short.exe

414670 ??   T0:00.79

/home/htl10/tmp-build/gcc-4.7.1-build4/gcc/testsuite/gcc/atomic-other-longlong.exe

414820 ??   T0:00.15

/home/htl10/tmp-build/gcc-4.7.1-build/gcc/testsuite/g++/atomics-2.exe

427365 ??   T0:00.27

/home/htl10/tmp-build/gcc-4.7.2-build/gcc/testsuite/gcc/atomic-other-int.exe

[Bug testsuite/54698] New: make -j 3 -k check, trying to do parallel check at the top level, go around in circles.

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54698



 Bug #: 54698

   Summary: make -j 3 -k check, trying to do parallel check at the

top level,  go around in circles.

Classification: Unclassified

   Product: gcc

   Version: 4.7.0

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: testsuite

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: ht...@users.sourceforge.net





"make -j 3 -k check", trying to do parallel check at the top level, go around

in circles. I tried that to save some time, but want to make sure I have a full

report, and noticed that some targets are remade over and over. (perhaps

failure was never registered, etc).

[Bug testsuite/54698] make -j 3 -k check, trying to do parallel check at the top level, go around in circles.

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54698



--- Comment #2 from Hin-Tak Leung  
2012-09-25 03:53:58 UTC ---

(In reply to comment #1)

> It works for me and I have been using -j5 even -j32 recently too.



with "-k"?

[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54448



Hin-Tak Leung  changed:



   What|Removed |Added



  Known to work||4.3.3, 4.3.6, 4.4.1, 4.4.7

  Known to fail||4.5.0, 4.5.4



--- Comment #2 from Hin-Tak Leung  
2012-09-25 04:41:14 UTC ---

See my testsuite results for various versions submitted on 25 sept 2012:

http://gcc.gnu.org/ml/gcc-testresults/2012-09/



The issue seems to happen with 4.5.0.

[Bug testsuite/54698] make -j 3 -k check, trying to do parallel check at the top level, go around in circles.

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54698



--- Comment #6 from Hin-Tak Leung  
2012-09-25 08:07:43 UTC ---

Hmm... I still think I saw it at least twice so I stopped using -j X in my

recent runs of checking many of gcc 4.3.x-4.7.x on tru64. Does "make -k check"

try to make the language/lib targets if some of them failed?

[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54448



--- Comment #5 from Hin-Tak Leung  
2012-09-28 15:51:37 UTC ---

(In reply to comment #4)

> How is GCC configured?



Just "/where/source/is/configure" with no options. You can see it at the bottom

of :

http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02452.html for 4.5.0

http://gcc.gnu.org/ml/gcc-testresults/2012-09/msg02457.html for 4.5.1



all built with 4.3.3. 



(sorry the one for 4.5.0 has an extra --enable-obsolete - I must have copied it

blindly because 4.7.x for Tru64 needed it. But you can see the others on sept

25 

http://gcc.gnu.org/ml/gcc-testresults/2012-09/

- there are 20+ of them for various versions, and the 4.5.x and 4.6.x should be

without that).

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.5.2

--- Comment #5 from Hin-Tak Leung  
2010-12-17 12:22:08 UTC ---
(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#

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |
  Known to fail||4.6.2

--- Comment #15 from Hin-Tak Leung  
2012-05-07 03:21:20 UTC ---
/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

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.6.3

--- Comment #16 from Hin-Tak Leung  
2012-05-07 10:25:19 UTC ---
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...

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #18 from Hin-Tak Leung  
2012-05-08 14:05:56 UTC ---
Created attachment 27346
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27346
one set of those checksum files. tar.gz'ed

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

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #19 from Hin-Tak Leung  
2012-05-08 14:07:03 UTC ---
Created attachment 27347
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27347
another set of those checksum files. tar.gz'ed

I think this one is from make bootstrap4

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #20 from Hin-Tak Leung  
2012-05-08 14:08:17 UTC ---
Created attachment 27348
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27348
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.

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #21 from Hin-Tak Leung  
2012-05-08 14:15:52 UTC ---
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.

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #23 from Hin-Tak Leung  
2012-05-08 20:48:25 UTC ---
(In reply to comment #22)
> > --- Comment #21 from Hin-Tak Leung  
> > 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.

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #42 from Hin-Tak Leung  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #40)

> 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.


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 $@;
}
--

[Bug bootstrap/44959] [4.6 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #43 from Hin-Tak Leung  ---
(In reply to r...@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).

[Bug libstdc++/54448] many failures with /sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init" unresolved

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54448

--- Comment #6 from Hin-Tak Leung  ---
The latest with 4.6.4 and 4.7.3 :
http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00048.html
http://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00049.html

seems to be a lot healthier.

During the course of the latest round, I realised that it seems that GNU strip
from GNU binutils seems to confuse the configure system
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959 bootstrap failed at
Comparing stages 2 and 3) on -gtoggle ; so I am putting /usr/local/bin *last*,
instead of first as previously.

gcc these days requires GNU tar to extract, and GNU make, GNU bash to configure
and make, so it is almost a habit to put /usr/local/bin first, but GNU strip
certainly seems to behave differently from DEC strip.

Would any of GNU binutils causes
"/sbin/loader: Error: libstdc++.so.6: symbol "__pthread_mutex_init"
unresolved"? If there is a simple test, I can try.

[Bug bootstrap/54447] gmp in source does not work on alphaev68-dec-osf5.1a

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54447

--- Comment #2 from Hin-Tak Leung  ---
Sorry I no longer recall the details from 5 years ago, but it seems that I have
managed to build later versions of gcc 3 years ago:

https://gcc.gnu.org/ml/gcc-testresults/2014-01/msg00048.html

and I seemed to have figure out bug 44959 also, so this is perhaps no longer
relevant, especially given that the alpha platform is no longer supported.

Please feel free to close.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

Hin-Tak Leung  changed:

   What|Removed |Added

 CC||htl10 at users dot 
sourceforge.net

--- Comment #9 from Hin-Tak Leung  ---
Did the change make it into 4.9.2? I recently tried that
and found that I need the explicit --sysroot:
https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html

Otherwise it fails during the stage1-fixincludes stage.
(luckily I saw the tips and reference to this bug report
in the older buildstat).

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

--- Comment #12 from Hin-Tak Leung  ---
(In reply to howarth from comment #10)
> This change was reverted when Apple abandoned the idea of removing the
> /usr/include. They didn't appreciate the number of packages (like python)
> which would require the changes to also find the new location of the
> /usr/include.

(In reply to howarth from comment #11)
> Also, if you can't find /usr/include on OS X, that means you need to install
> the Command Line Tools with 'xcode-select --install'.

Have Apple really abandoned the idea of removing /usr/include ? xcode 6.1 ships
all the headers under the SDK places; indeed as you said, running 'xcode-select
--install' prompts for installing the command line developer's tools, which
seems
to install /usr/include ; but the Command Line Developer's Tool installed this
way is only version 5.1 (i.e. against an older version of xcode, I think).

Also I think it could be a bit more user friendly - e.g. test for the existence
of /usr/include, and set "--with-sysroot=\"`xcrun --show-sdk-path`\" if
/usr/include does not exist? It isn't much more code, but would make a lot of
difference in user-friendliness.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

--- Comment #14 from Hin-Tak Leung  ---
(In reply to howarth from comment #13)
>
> If we made any change, I would rather it be a check in FSF gcc's
> configure for the presence of /usr/include on darwin which provided the
> appropriate error message to the user that the Command Line Tools needs to
> be installed.

I don't think mandating Command Line Tools would be a good idea - I think in
that case you can have a reverse problem when your intention is to build stuff
for other people: you build x intended for others, you have /usr/include but
others don't, x made assumptions about the intended users having the same stuff
as yours, and it doesn't work on the intended user's machine, or have
mysterious errors.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57792

--- Comment #18 from Hin-Tak Leung  ---
(In reply to m...@gcc.gnu.org from comment #15)
> Mandating commands line tools is fine.  Would be nice if everything worked
> flawlessly if no optional package had to be installed, but I'm pragmatic.

The current behavior is definitely wrong: without command line tools and
without --with-sysroot (i.e. just plain ./configure), ./configure returns
success, but only fail to 'make' towards the end of stage1 when the build
system tries to do the 'stage1-fixincludes' target.

./configure should either auto-add the --with-sysroot (as the reverted fix
did), or abort with an appropriate message, like the requirement for
gmp/mpfr/mpc. successful ./configure then failing part-way through make is bad.

(In reply to howarth from comment #17)
> You have to remember that Apple expects you to build everything from within
> the Xcode projects while the Command Line Tools package exists to handle
> building outside of that mechanism. The unfortunate fact is that far too
> much software explicitly expects headers in /usr/include to avoid installing
> the Command Line Tools. In the fink project, we get endless bug reports from
> users who fail to install the Command Line Tools.

Not really. Actually xcode 6.1 seem to ships all the command line tools. doing
'xcode-select --install' install a much older(?) command line tools plus
headers in /usr/include. I don't know if Apple is going to keep that in-sync,
but there might be a danger of the headers in /usr/include not really
describing the system.

Also, people who DIY are supposed to go through all the troubles... you still
haven't addressed the issue of new gcc (+ xcode building it with) may generate
stuff that have additional dependencies on /usr/include, if /usr/include is
around, and therefore not suitable when one is building things for others.

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831

Hin-Tak Leung  changed:

   What|Removed |Added

 CC||htl10 at users dot 
sourceforge.net

--- Comment #37 from Hin-Tak Leung  ---
(In reply to Sami Farin from comment #35)
> binutils-2.24-13.fc21
> haven't tried latest from git://sourceware.org/git/binutils-gdb.git

Apparently that's due to a redhat-specific patch.
https://bugzilla.redhat.com/show_bug.cgi?id=1149660
https://bugzilla.redhat.com/show_bug.cgi?id=1174065

If you upgrade to binutils-2.24-29.fc21+ , building 64-bit archive on 64-bit
host would work; but it would still segfault building 32-bit archive on 64-bit
host. Just upgraded to fedora 21 and gotten bitten by it, and still looking for
a solution.

[Bug lto/53831] [4.7 Regression] Virtuals missing in LTO symtab

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53831

--- Comment #38 from Hin-Tak Leung  ---
This is the only reference I have about the redhat specific patch. (from
redhat's binutils packaging git). I think "H.J." is "H.J.Lu" but I can't find
anything further - I am hoping there is an updated patch, or any kind of blog
or mailing list post that explains what the patch tries to do.

commit d43b72113c5879ddde546867dfe23baaccf35c1f
Author: Nick Clifton 
Date:   Fri May 17 08:42:58 2013 +0100

Import H.J.'s patch to add support for kernel ld -r modules.

[Bug ipa/64390] New: "-shared" does not resolve symbols from lto generated archives

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64390

Bug ID: 64390
   Summary: "-shared" does not resolve symbols from lto generated
archives
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: htl10 at users dot sourceforge.net

Upgrading to 4.9.2 from 4.8.x, building R (http://www.r-project.org) with fto
fails. ("./configure --enable-lto AR=gcc-ar").

Specifically, it builds a few static archives of external libraries then tries
build a shared libraries out of it. A simplified procedure is like this:

gcc -flto -c -o routine1.o routine1.c
...
gcc -flto -c -o used_by_routine1.o used_by_routine1.c
...
gcc-ar cr libextra.a used_by_routine1.o ...
...
gcc -shared -o liboutput.so routine1.o ... libextra.a ...

the output shared library is not able to resolve any symbols with libextra.a's
content.

I found two workarounds:

- putting all the dependent *.o on the command line instead of the archive
itself.

- prepending/appending the extra libraries with the whole archive linker
directives: i.e. "-Wl,--whole-archive ../extra/tre/libtre.a
-Wl,--no-whole-archive"

I realise generating shared libraries from static archive is daft, but that's
how R is built.

[Bug ipa/64390] "-shared" does not resolve symbols from lto generated archives

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64390

--- Comment #1 from Hin-Tak Leung  ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --enable-multilib --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.9.2-20141101/obj-x86_64-redhat-linux/cloog-install
--enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.9.2 20141101 (Red Hat 4.9.2-1) (GCC) 

ar comes from:
binutils-2.24-30.fc21.x86_64

There is a lto related build in binutils-2.24-29- .

[Bug ipa/64390] "-shared" does not resolve symbols from lto generated archives

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64390

--- Comment #3 from Hin-Tak Leung  ---
I wonder if it isn't '-shared' but that a mixture of object files and archives
are being used. See also:

http://stackoverflow.com/questions/27372667/undefined-reference-cross-compiling-static-libraries-with-lto-under-gcc

I 'll give binutils 2.25 a try soon - I have got something building atm; it
looks like I need to move my system's ar & ld aside to make sure the new ones
are used, which is not trivial, and can't happen while I have something
building anyway...

[Bug ipa/64390] "-shared" does not resolve symbols from lto generated archives

[htl10 at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64390

Hin-Tak Leung  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Hin-Tak Leung  ---
(In reply to H.J. Lu from comment #2)
> Can you try binutils 2.25?

Trying binutils 2.25 was a great help. ranlib of 2.25 actually emit a warning
about being ran on lto archives (which ranlib of 2.24 does not - I checked
again). So the part of R I had problem building and had to work around, was
running AR and RANLIB separately; other parts were doing AR in one step, so
setting AR was sufficient except where it failed, only once. Setting
RANLIB=gcc-ranlib in addition to AR=gcc-ar works.

I would have been nice if ranlib emit a warning (so it was added in 2.25)
instead of silently going ahead; incidently ar on redhat segaulted in a
slightly out of date patch with your name on it:

" Import H.J.'s patch to add support for kernel ld -r modules."

(see https://bugzilla.redhat.com/show_bug.cgi?id=1149660#c16)

and the fix to the segfault is identical to what you already did two years ago:

commit d7f8c5c183adcaa3c313150486e15ea703a65576
Author: H.J. Lu 
Date:   Mon Jun 4 06:44:34 2012 -0700

Set tdata.plugin_data first

(https://bugzilla.redhat.com/show_bug.cgi?id=1149660#c17)

So it would be nice if you could check and make sure that redhat is shipping
the latest of the 'ld -r' diff, and/or have a look at the 32-bit segault also?
( https://bugzilla.redhat.com/show_bug.cgi?id=1174065 )

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.6.0

--- Comment #7 from Hin-Tak Leung  
2011-04-30 07:16:11 UTC ---
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

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.5.3

--- Comment #8 from Hin-Tak Leung  
2011-04-30 10:54:00 UTC ---
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

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.4.6

--- Comment #8 from Hin-Tak Leung  
2011-04-30 18:59:41 UTC ---
4.4.6 also fails.

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

--- Comment #9 from Hin-Tak Leung  
2011-04-30 19:01:44 UTC ---
The last part of the 4.4.6 failure:
--
libtool: link: (cd ".libs" && rm -f "libgcj-tools.so.10" && ln -s
"libgcj-tools.so.10.0.0" "libgcj-tools.so.10")
libtool: link: (cd ".libs" && rm -f "libgcj-tools.so" && ln -s
"libgcj-tools.so.10.0.0" "libgcj-tools.so")
libtool: link: /usr/local/alphaev68-dec-osf5.1a/bin/ar rc .libs/libgcj-tools.a 
classpath/tools/libgcj_tools_la-tools.o
libtool: link: /usr/local/alphaev68-dec-osf5.1a/bin/ranlib .libs/libgcj-tools.a
libtool: link: ( cd ".libs" && rm -f "libgcj-tools.la" && ln -s
"../libgcj-tools.la" "libgcj-tools.la" )
/usr/local/bin/bash ./libtool --tag=GCJ --mode=link
/home/htl10/tmp-build/gcc-446-obj/gcc/gcj
-B/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/
-B/home/htl10/tmp-build/gcc-446-obj/gcc/
-L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava -mieee -g -O2
 -o jv-convert --main=gnu.gcj.convert.Convert -rpath /usr/local/lib
-shared-libgcc   
-L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/.libs
libgcj.la 
libtool: link: /home/htl10/tmp-build/gcc-446-obj/gcc/gcj
-B/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/
-B/home/htl10/tmp-build/gcc-446-obj/gcc/ -mieee -g -O2 -o .libs/jv-convert
--main=gnu.gcj.convert.Convert -shared-libgcc 
-L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/.libs
-L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava
./.libs/libgcj.so -lpthread -lrt -Wl,-rpath -Wl,/usr/local/lib
/bin/ld:
Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
/bin/ld: Usage: /bin/ld [options] file [...]
collect2: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1
make[3]: Leaving directory
`/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj'
make: *** [all] Error 2

-

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

--- Comment #10 from Hin-Tak Leung  
2011-04-30 20:46:02 UTC ---
Just upgrading from libtool 2.2 to 2.4 to see if that works. This looks
relevant 
http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00305.html ?
since the next to current libtool 2.2.10 was on 09-Jun-2010, this probably
means it has to be libtool 2.4 or a snapshot.

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

--- Comment #11 from Hin-Tak Leung  
2011-05-01 10:14:49 UTC ---
This really looks like a libtool/automake/autoconf problem, and it seems that
libjava has its own libtool bundle?

Anyway, upgrading the system libtool to 2.4 does not improve.

[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967

Hin-Tak Leung  changed:

   What|Removed |Added

 CC||htl10 at users dot
   ||sourceforge.net

--- Comment #3 from Hin-Tak Leung  
2011-05-01 19:01:17 UTC ---
Hmm, I was looking around for other bugs and wondering if I should fail one -
just finished testing 4.4.6 on alphaev68-dec-osf5.1a and 

(my own previous result, on the same machine):
http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01338.html

4.4.5:
=== libgomp Summary ===

# of expected passes2463
# of unexpected failures9
# of unsupported tests  2

and the new one in 4.4.6 (I'll post to gcc-testresults@gcc soon):

 === libgomp Summary ===

# of expected passes1610
# of unexpected failures466
# of unsupported tests2

so something has gone very wrong. with 4.4.6.

Since HP owns Tru64 these days, I'd be interested in hppa-hp-hpux11.31's 4.4.6
's test result.

[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967

--- Comment #5 from Hin-Tak Leung  
2011-05-01 22:02:03 UTC ---
(In reply to comment #4)
> Regarding comment #3, look at the libgomp test log file to see why the
> tests are failing on alphaev68-dec-osf5.1a.  I'm certain the problem
> is different from the hppa2.0w-hp-hpux11.31 issue, so a new PR
> should be opened.

Will do. am checking bug 40894 for 4.4.6 at the moment. When I finish updating
the status of that I'll send the test result to test-results, and file  a new
bug.

[Bug libgomp/46967] lots of testsuite failures with libgomp on hppa-hp-hpux11.31

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46967

--- Comment #6 from Hin-Tak Leung  
2011-05-01 22:24:08 UTC ---
Filed Bug 48841 for the alphaev68 libgomp failure and attached my test summary,
in case somebody wants to compare to hppa 4.4.6.

[Bug bootstrap/40894] [4.4/4.5/4.6/4.7 Regression] bootstrap4-lean failed crtfastmath.o comparision

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.4.6

--- Comment #9 from Hin-Tak Leung  
2011-05-01 22:27:42 UTC ---
4.4.6 failed at same place.

make[2]: Entering directory `/home/htl10/tmp-build/gcc-446-obj-2'
make[3]: Entering directory `/home/htl10/tmp-build/gcc-446-obj-2'
rm -f stage_current
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj-2'
Comparing stages 3 and 4
Bootstrap comparison failure!
./crtfastmath.o differs
make[2]: *** [compare3] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj-2'
make[1]: *** [stage4-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj-2'
make: *** [bootstrap4-lean] Error 2
bash-2.05a# objdump -Dxzs stage3-gcc/crtfastmath.o > stage3-dump
bash-2.05a# objdump -Dxzs stage4-gcc/crtfastmath.o > stage4-dump
bash-2.05a# diff -u  stage3-dump stage4-dump
--- stage3-dump2011-05-01 23:14:28.0 +0100
+++ stage4-dump2011-05-01 23:14:41.0 +0100
@@ -1,6 +1,6 @@

-stage3-gcc/crtfastmath.o: file format ecoff-littlealpha
-stage3-gcc/crtfastmath.o
+stage4-gcc/crtfastmath.o: file format ecoff-littlealpha
+stage4-gcc/crtfastmath.o
 architecture: alpha, flags 0x0035:
 HAS_RELOC, HAS_LINENO, HAS_SYMS, HAS_LOCALS
 start address 0x
@@ -70,7 +70,7 @@
  0010 00301f22 10807da7 00405b6b 0100ba27  .0."..}..@[k...'
  0020 2480bd23 5ea7 1000de23 0180fa6b  $..#..^#...k
 Contents of section .xdata:
- 0030 3100 02000204    1...
+ 0030 0100 02000204    
 Contents of section .pdata:
  0040  ecff
 Contents of section .lita:
@@ -100,7 +100,7 @@
 Disassembly of section .xdata:

 0030 <.xdata>:
-  30:31 00 00 00 call_pal0x31
+  30:01 00 00 00 call_pal0x1
   34:02 00 02 04 .long 0x4020002
   38:00 00 00 00 halt
   3c:00 00 00 00 halt
bash-2.05a#

[Bug bootstrap/40894] [4.4/4.5/4.6/4.7 Regression] bootstrap4-lean failed crtfastmath.o comparision

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894

--- Comment #10 from Hin-Tak Leung  
2011-05-01 22:30:55 UTC ---
Could this be some kind of text<->num conversion bug? I can't help but thinking
0x31 is '1' in ascii character, which is 0x01 in value.

[Bug libgomp/48841] New: [regression] lot more libgomp testsuite failures compared to 4.4.5

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841

   Summary: [regression] lot more libgomp testsuite failures
compared to 4.4.5
   Product: gcc
   Version: 4.4.6
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ht...@users.sourceforge.net


Created attachment 24160
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24160
The full soon-to-post-to-gcc-testresults test summary

My 4.4.5 result, on the same machine:
http://gcc.gnu.org/ml/gcc-testresults/2010-12/msg01338.html

4.4.5:
=== libgomp Summary ===

# of expected passes2463
# of unexpected failures9
# of unsupported tests  2

 === libgomp Summary ===

# of expected passes1610
# of unexpected failures466
# of unsupported tests2

so something has gone very wrong with 4.4.6.

[Bug libgomp/48841] [regression] lot more libgomp testsuite failures compared to 4.4.5

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841

--- Comment #1 from Hin-Tak Leung  
2011-05-01 22:46:34 UTC ---
attachment posted as:
http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00074.html
after prepending with some notes.

Mentioned the issue but forgot to mention the actual bug number, but I am sure
somebody will find this report if they need to.

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.5.0, 4.5.1

--- Comment #3 from Hin-Tak Leung  
2010-12-15 01:53:41 UTC ---
(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
--

[Bug bootstrap/40894] [4.4/4.5/4.6 Regression] bootstrap4-lean failed crtfastmath.o comparision

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||
  Known to fail||4.4.5

--- Comment #8 from Hin-Tak Leung  
2010-12-15 05:17:11 UTC ---
Just try with 4.4.5, still fails at the same place:

make[2]: Entering directory `/home/htl10/tmp-build/gcc-445-obj'
make[3]: Entering directory `/home/htl10/tmp-build/gcc-445-obj'
rm -f stage_current
make[3]: Leaving directory `/home/htl10/tmp-build/gcc-445-obj'
Comparing stages 3 and 4
Bootstrap comparison failure!
./crtfastmath.o differs
make[2]: *** [compare3] Error 1
make[2]: Leaving directory `/home/htl10/tmp-build/gcc-445-obj'
make[1]: *** [stage4-bubble] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-445-obj'
make: *** [bootstrap4-lean] Error 2
bash-2.05a#  
bash-2.05a# objdump -Dxzs stage3-gcc/crtfastmath.o > stage3-dump
bash-2.05a# objdump -Dxzs stage4-gcc/crtfastmath.o > stage4-dump
bash-2.05a# diff -u  stage3-dump stage4-dump
--- stage3-dump2010-12-15 05:03:03.0 +
+++ stage4-dump2010-12-15 05:03:18.0 +
@@ -1,6 +1,6 @@

-stage3-gcc/crtfastmath.o: file format ecoff-littlealpha
-stage3-gcc/crtfastmath.o
+stage4-gcc/crtfastmath.o: file format ecoff-littlealpha
+stage4-gcc/crtfastmath.o
 architecture: alpha, flags 0x0035:
 HAS_RELOC, HAS_LINENO, HAS_SYMS, HAS_LOCALS
 start address 0x
@@ -70,7 +70,7 @@
  0010 00301f22 10807da7 00405b6b 0100ba27  .0.".@[k...'
  0020 2480bd23 5ea7 1000de23 0180fa6b  $..#..^#...k
 Contents of section .xdata:
- 0030 3100 02000204    1...
+ 0030 0100 02000204    
 Contents of section .pdata:
  0040  ecff
 Contents of section .lita:
@@ -100,7 +100,7 @@
 Disassembly of section .xdata:

 0030 <.xdata>:
-  30:31 00 00 00 call_pal0x31
+  30:01 00 00 00 call_pal0x1
   34:02 00 02 04 .long 0x4020002
   38:00 00 00 00 halt
   3c:00 00 00 00 halt
bash-2.05a#

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||
  Known to fail||

--- Comment #4 from Hin-Tak Leung  
2010-12-15 14:57:27 UTC ---
Still same problem with 4.4.5. (haven't tried 4.5.1 since it is still affected
by bug 44959).

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

--- Comment #6 from Hin-Tak Leung  
2010-12-16 00:22:07 UTC ---
Created attachment 22778
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22778
alphaev68-dec-osf5.1a/libjava/config.log from 4.4.5

4.4.5,  alphaev68-dec-osf5.1a/libjava/config.log
from
CONFIG_SHELL=/usr/local/bin/bash ../gcc-4.4.5/configure && \
CONFIG_SHELL=/usr/local/bin/bash /usr/localbin/make

(/usr/local/bin/make is GNU make, system make isn't suitable for gcc - known
problem)

I'll keep the build tree for a while in case something else is needed.

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to fail||4.4.5

--- Comment #7 from Hin-Tak Leung  
2010-12-16 00:23:11 UTC ---
known to fail with 4.4.5.

[Bug libgomp/48841] [regression] lot more libgomp testsuite failures compared to 4.4.5

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841

--- Comment #4 from Hin-Tak Leung  
2011-08-02 11:03:23 UTC ---
> Apart from that, why are you wasting your time with GCC 4.4 which I don't test
any longer?  GCC 4.5 and 4.6 should be fine and have seen lots of bug fixes.

4.5 does not build correctly.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #10 from Hin-Tak Leung  
2011-08-02 11:08:25 UTC ---
> 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

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

--- Comment #14 from Hin-Tak Leung  
2011-08-02 23:31:30 UTC ---
(In reply to comment #13)
> One other possible problem: please avoid relative pathnames to configure and
> an object directory that is a subdir of the source tree.  Better do (say)
> 
> mkdir /vol/gcc/obj/gcc-4.6.1
> cd /vol/gcc/obj/gcc-4.6.1
> /vol/gcc/src/gcc-4.6.1/configure 

Tried specifying full path instead of relative path in configure. Still exactly
the same problem. With 4.6.1 (source is untar'ed to
/home/htl10/tmp-build/gcc-4.4.6):

cd /home/htl10/tmp-build/
mkdir gcc-446-obj
cd gcc-446-obj
/home/htl10/tmp-build/gcc-4.4.6/configure
make

last part of output:
---
libtool: link: /home/htl10/tmp-build/gcc-446-obj/gcc/gcj
-B/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/
-B/home/htl10/tmp-build/gcc-446-obj/gcc/ -mieee -g -O2 -o .libs/jv-convert
--main=gnu.gcj.convert.Convert -shared-libgcc 
-L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava/.libs
-L/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava
./.libs/libgcj.so -lpthread -lrt -Wl,-rpath -Wl,/usr/local/lib
/bin/ld:
Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
/bin/ld: Usage: /bin/ld [options] file [...]
collect2: ld returned 1 exit status
make[3]: *** [jv-convert] Error 1
make[3]: Leaving directory
`/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory
`/home/htl10/tmp-build/gcc-446-obj/alphaev68-dec-osf5.1a/libjava'
make[1]: *** [all-target-libjava] Error 2
make[1]: Leaving directory `/home/htl10/tmp-build/gcc-446-obj'
make: *** [all] Error 2
bash-2.05a# 

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

--- Comment #12 from Hin-Tak Leung  
2011-08-03 15:29:50 UTC ---
(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.

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||4.6.1

--- Comment #13 from Hin-Tak Leung  
2011-08-03 15:32:31 UTC ---
adding 4.6.1 known to work. pending retrying 4.5.3/4.6.0

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||4.6.1

--- Comment #16 from Hin-Tak Leung  
2011-08-03 15:38:30 UTC ---
(In reply to comment #15)

> > Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4 
> 

> What I do see is that if you add some -W option to ld, you get exactly
> the message you observe.  E.g.

That's stating the obvious... it is essentially what the error message is
complaining ('flags must be ordered in some way")

> Do you happen to have some environment variable set to -W?
> Though I have found no hint that ld would check for this, it's a
> possibility.

No I don't - just tried export |grep W . In any case, 4.6.1 does not show this
problem, so it seems to be fixed in 4.6.1 somehow; and it is *not*
full/relative path related.

[Bug libgomp/48841] [regression] lot more libgomp testsuite failures compared to 4.4.5

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841

--- Comment #6 from Hin-Tak Leung  
2011-08-03 22:26:13 UTC ---
(In reply to comment #5)

> Please follow the directions I gave in that PR.  Start with a standard
> configure; make setup, no bootstrap-lean4, no relative paths to the
> source dir.  This works just fine for me, so instead of insisting on
> trying untested paths, first determine if the regular one works.  Even
> gcc 4.5 is old by now...

Okay... did the plain configure and make and no relative path, and watching my
4.6.1 "make -k check" - I'll be summiting the result later to the testsuite
mailing list; but it is currently spilling a lot of 


Unaligned access pid=353493  va=0x14000ad5e pc=0x3ff81006d00
ra=0x3ff81006c44 inst=0xb3e9
---

messages, with a different . and I looked, and it is currently doing
make check inside libgomp . So it looks like there was some kind of alignment
regression after 4.4.5 .

[Bug libgomp/48841] [regression] lot more libgomp testsuite failures compared to 4.4.5

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||4.4.5, 4.6.1
  Known to fail||4.4.6

--- Comment #7 from Hin-Tak Leung  
2011-08-03 23:08:47 UTC ---
Please ignore last comment 6. With 4.6.1:

=== libgomp Summary ===

# of expected passes2586
# of unsupported tests3

So the problem is not seen in 4.6.1.

[Bug bootstrap/40894] [4.4/4.5/4.6/4.7 Regression] bootstrap4-lean failed crtfastmath.o comparision

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894

Hin-Tak Leung  changed:

   What|Removed |Added

  Known to work||4.6.1

--- Comment #11 from Hin-Tak Leung  
2011-08-05 01:26:32 UTC ---
Tried 4.6.1:

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 bootstrap4-lean

and it worked.

[Bug bootstrap/44959] [4.5 Regression] bootstrap failed at Comparing stages 2 and 3

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44959

Hin-Tak Leung  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #14 from Hin-Tak Leung  
2011-08-05 05:38:58 UTC ---
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
---

[Bug bootstrap/40894] [4.4/4.5/4.6/4.7 Regression] bootstrap4-lean failed crtfastmath.o comparision

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894

Hin-Tak Leung  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #12 from Hin-Tak Leung  
2011-08-05 05:43:18 UTC ---
4.6.1 worked. 4.5.x fails earlier with Bug 44959 .

[Bug libgcj/40947] Invalid flag usage: Wl,-rpath, -Wx,-option must appear after -_SYSTYPE_SVR4

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40947

Hin-Tak Leung  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #18 from Hin-Tak Leung  
2011-08-05 05:47:12 UTC ---
4.4.6 fails, 4.5.x fails earlier in a different Bug 44959 ; 4.6.1 works so
closing.

[Bug libgomp/48841] [regression] lot more libgomp testsuite failures compared to 4.4.5

[htl10 at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48841

Hin-Tak Leung  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution||FIXED

--- Comment #10 from Hin-Tak Leung  
2011-08-05 23:44:55 UTC ---
Most strange -re-run 4.4.6 and got a different answer from previous
(http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00074.html) - every part of
the resulting summary file is identical, except the libgomp section.
Here is the old 4.4.5, new 4.4.6, and the 4.6.1 from a few days ago:

4.4.5:
=== libgomp Summary ===

# of expected passes2463
# of unexpected failures9
# of unsupported tests  2

4.4.6
=== libgomp Summary ===

# of expected passes2511
# of unexpected failures9
# of unsupported tests2

4.6.1
=== libgomp Summary ===

# of expected passes2586
# of unsupported tests3

These numbers make a lot more sense. The machine has not been upgraded nor used
all these times, so the only two changes are (1) use of absolute path in
configure, (2) during this run (in 4.6.1) I noticed /tmp was a bit small (it
failed quite early on with libnumber or libiberty) so set TMIDIR to a different
disk.

I don't think it is the path, but it is possible I just didn't notice a
not-enough temp space error; the other possibillity is some
transient/intermittent error (the alignment?). Anyway, since 4.6.1 seems to
work and fixes most of the regressions or what not, I am happy to let this one
go.