[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #44 from Jing Yu jingyu at gcc dot gnu.org 2012-02-22 22:04:45 UTC --- Author: jingyu Date: Wed Feb 22 22:04:39 2012 New Revision: 184493 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184493 Log: 2012-02-21 Jing Yu jin...@google.com Google Ref 47894 Backport from mainline r177933, r175181, r177963, r178116, r183299. 2011-08-20 H.J. Lu hongjiu...@intel.com PR other/46770 * config.gcc (tm_file): Add initfini-array.h if .init_arrary/.fini_array are supported. * crtstuff.c: Don't generate .ctors nor .dtors sections if USE_INITFINI_ARRAY is defined. * output.h (default_elf_init_array_asm_out_constructor): New. (default_elf_fini_array_asm_out_destructor): Likewise. * varasm.c (elf_init_array_section): Likewise. (elf_fini_array_section): Likewise. (get_elf_initfini_array_priority_section): Likewise. (default_elf_init_array_asm_out_constructor): Likewise. (default_elf_fini_array_asm_out_destructor): Likewise. * config/initfini-array.h: New. 2011-06-18 H.J. Lu hongjiu...@intel.com PR other/49325 * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if .init_array can be used with .ctors on targets. * configure: Regenerated. 2011-08-22 H.J. Lu hongjiu...@intel.com * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Error if __ELF__ isn't defined. * configure: Regenerated. 2011-08-26 Rainer Orth r...@cebitec.uni-bielefeld.de PR target/50166 * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Check count in main. * configure: Regenerate. 2012-01-19 Jakub Jelinek ja...@redhat.com PR bootstrap/50237 * config/initfini-array.h: Guard content of the header with #ifdef HAVE_INITFINI_ARRAY. * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file. Add initfini-array.h to tm_file here. * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker test. * config.gcc: Don't add initfini-array.h to tm_file here. * configure: Regenerated. Added: branches/google/gcc-4_6/gcc/config/initfini-array.h Modified: branches/google/gcc-4_6/gcc/ChangeLog.google-4_6 branches/google/gcc-4_6/gcc/acinclude.m4 branches/google/gcc-4_6/gcc/configure branches/google/gcc-4_6/gcc/configure.ac branches/google/gcc-4_6/gcc/crtstuff.c branches/google/gcc-4_6/gcc/output.h branches/google/gcc-4_6/gcc/varasm.c
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #45 from Jing Yu jingyu at gcc dot gnu.org 2012-02-22 22:26:45 UTC --- Author: jingyu Date: Wed Feb 22 22:26:40 2012 New Revision: 184494 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184494 Log: 2012-02-21 Jing Yu jin...@google.com Bakcport r175181, r177963, r178116, r183299 from mainline. 2011-06-18 H.J. Lu hongjiu...@intel.com PR other/49325 * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Properly check if .init_array can be used with .ctors on targets. * configure: Regenerated. 2011-08-22 H.J. Lu hongjiu...@intel.com * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Error if __ELF__ isn't defined. * configure: Regenerated. 2011-08-26 Rainer Orth r...@cebitec.uni-bielefeld.de PR target/50166 * acinclude.m4 (gcc_AC_INITFINI_ARRAY): Check count in main. * configure: Regenerate. 2012-01-19 Jakub Jelinek ja...@redhat.com PR bootstrap/50237 * config/initfini-array.h: Guard content of the header with #ifdef HAVE_INITFINI_ARRAY. * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file. Add initfini-array.h to tm_file here. * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker test. * config.gcc: Don't add initfini-array.h to tm_file here. * configure: Regenerated. Modified: branches/google/gcc-4_6_2-mobile/gcc/ChangeLog.google-4_6 branches/google/gcc-4_6_2-mobile/gcc/acinclude.m4 branches/google/gcc-4_6_2-mobile/gcc/config.gcc branches/google/gcc-4_6_2-mobile/gcc/config/initfini-array.h branches/google/gcc-4_6_2-mobile/gcc/configure branches/google/gcc-4_6_2-mobile/gcc/configure.ac
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #36 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:43:58 UTC --- Author: jakub Date: Thu Jan 19 10:43:54 2012 New Revision: 183299 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183299 Log: PR bootstrap/50237 * config/initfini-array.h: Guard content of the header with #ifdef HAVE_INITFINI_ARRAY. * configure.ac: Move gcc_AC_INITFINI_ARRAY much later into the file. Add initfini-array.h to tm_file here. * acinclude.m4 (gcc_AC_INITFINI_ARRAY): For non-ia64 do a linker test. * config.gcc: Don't add initfini-array.h to tm_file here. * configure: Regenerated. Modified: trunk/gcc/ChangeLog trunk/gcc/acinclude.m4 trunk/gcc/config.gcc trunk/gcc/config/initfini-array.h trunk/gcc/configure trunk/gcc/configure.ac
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #37 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:50:13 UTC --- Rainer/Andrew, please test this in your configurations.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #38 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-19 16:08:44 UTC --- --- Comment #37 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 10:50:13 UTC --- Rainer/Andrew, please test this in your configurations. I've just successfully completed i386-pc-solaris2.1[01] gas/gld bootstraps without the previous --disable-initfini-array workaround. Thanks for fixing this. I'll check if support can unconditionally be enabled on Solaris if the tools support it. So far, ld -e 0 doesn't work: ld: fatal: entry point symbol '0' is undefined while omitting -e 0 gets a warning from gld: gld-2.22: warning: cannot find entry symbol _start; defaulting to 08048054 The latter is probably harmless, though, and we can just omit the -e 0 everwhere. While gld does merge the .init_array.N/.fini_array.N sections, Sun ld does not, so the test always fails if ld is in use. (Recent?) Sun as on Solaris 10 and 11/x86 work, too. On Solaris 11/SPARC, the test fails even with gas and gld 2.22: objdump -s -j .init_array conftest conftest: file format elf32-sparc-sol2 Contents of section .init_array: 20054 48484848 Still need to check why. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #39 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 16:17:29 UTC --- (In reply to comment #38) So far, ld -e 0 doesn't work: Well, if no Sun ld handles the section mixing right, it doesn't matter that much. We could just: .text .globl _start _start: at the end of the assembly otherwise. (Recent?) Sun as on Solaris 10 and 11/x86 work, too. It will still not default to --enable-initfini-array there, because of the glibc version check. Does Solaris dynamic linker handle .init_array etc. right (e.g. the old H.J.'s testcase from configure if compiled with GNU ld 2.22 or later)? If yes, from which versions? Shall it be based on just target tripplets for Solaris? On Solaris 11/SPARC, the test fails even with gas and gld 2.22: objdump -s -j .init_array conftest conftest: file format elf32-sparc-sol2 Contents of section .init_array: 20054 48484848 If it contains just two, then possibly the .ctors section has been kept around? I'd guess that H.J's testcase wouldn't succeed either. Anyway, marking this as fixed, details can be fixed up incrementally.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-19 16:27:44 UTC --- --- Comment #39 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 16:17:29 UTC --- (In reply to comment #38) So far, ld -e 0 doesn't work: Well, if no Sun ld handles the section mixing right, it doesn't matter that I've been in touch with the linker engineers about this issue, and they are not convinced that this section merging is mandated by the ELF spec. much. We could just: .text .globl _start _start: at the end of the assembly otherwise. True. (Recent?) Sun as on Solaris 10 and 11/x86 work, too. It will still not default to --enable-initfini-array there, because of the glibc version check. Does Solaris dynamic linker handle .init_array etc. right I know. (e.g. the old H.J.'s testcase from configure if compiled with GNU ld 2.22 or later)? If yes, from which versions? Shall it be based on just target tripplets for Solaris? I'm about to change the glibc check for Solaris. I'm pretty sure it works right on Solaris 11, and probably also on (patched) versions of Solaris 8 and up. If this is something that has been introduced after FCS, I'll perform the same ld version checking I did in other cases, since ld and ld.so.1 are guaranteed to be upgraded in lockstep. On Solaris 11/SPARC, the test fails even with gas and gld 2.22: objdump -s -j .init_array conftest conftest: file format elf32-sparc-sol2 Contents of section .init_array: 20054 48484848 If it contains just two, then possibly the .ctors section has been kept around? I'd guess that H.J's testcase wouldn't succeed either. Right, it aborts. Anyway, marking this as fixed, details can be fixed up incrementally. Agreed, bootstrapping again out of the box is the primary issue of this PR. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #41 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 16:32:08 UTC --- It isn't mandated by the ELF spec, but if the linker doesn't do that and either keeps .ctors and .init_array etc. separate, or merges them but without ensuring the right order, ctor/dtor priorities won't work correctly.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-19 16:36:56 UTC --- --- Comment #41 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-19 16:32:08 UTC --- It isn't mandated by the ELF spec, but if the linker doesn't do that and either keeps .ctors and .init_array etc. separate, or merges them but without ensuring the right order, ctor/dtor priorities won't work correctly. I know. The question is if adding this gld extension to Sun ld could be justified and if there's a spec the Oracle guys could use without reading the gld code. Especially in Solaris 11, many gld command line options and features have been added this name to improve compatibility. IIRC, there are other cases where gld merges sections when Sun ld does not. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #43 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-19 23:37:52 UTC --- (In reply to comment #37) Rainer/Andrew, please test this in your configurations. Yes it works for me now. Thanks for fixing this issue.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #35 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-17 16:00:44 UTC --- Created attachment 26352 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26352 gcc47-pr50237.patch Untested patch. For ia64 I've kept it (hopefully) as is, for other targets this attempts to detect the missing linker support using as/ld/objdump. There is no testing of the libc/dynamic linker though, what C libraries do support .init_array/.fini_array properly? For glibc I'd say at least all = 2.4, since 2.4 removed altogether support for configurations where linker didn't support .init_array, so perhaps we could AC_PREPROC_IFELSE and test __GLIBC__ and __GLIBC_MINOR__ macros. What other OSes support .init_array properly and would like it be enabled by default when neither --enable-initfini-array nor --disable-initfini-array is specified?
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #34 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-09 14:31:30 UTC --- Another possible fix is to drop autodetecting the feature (defaulting to the old behavior) and requiring --enable-init_array at configure time. HJ, please work on this, this is a real blocker. I prefer the explicit configure argument way for 4.7, we can switch to autodetection in a later release.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #33 from Andrew Pinski pinskia at gcc dot gnu.org 2012-01-09 00:54:10 UTC --- I now get this failure with gcc/go/go.o (and others) miscomparing. I have a new version of binutils installed in the prefix but not currently in the PATH. stage2 uses ctors and stage3 uses init_array. Now my work around is just to put the new binutils in the PATH but that should not be needed.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #32 from Jakub Jelinek jakub at gcc dot gnu.org 2011-12-07 22:06:04 UTC --- Author: jakub Date: Wed Dec 7 22:05:59 2011 New Revision: 182090 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=182090 Log: PR bootstrap/50237 * internal.h (_cpp_init_lexer): New prototype. * init.c (init_library): Call it. * lex.c (init_vectorized_lexer): Remove constructor attribute, add inline keyword. (HAVE_init_vectorized_lexer): Define. (_cpp_init_lexer): New function. Modified: trunk/libcpp/ChangeLog trunk/libcpp/init.c trunk/libcpp/internal.h trunk/libcpp/lex.c
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #31 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-12-01 20:25:27 UTC --- Getting rid of the attribute constructor in libcpp/lex.c isn't that hard either. Right, I'd apply the patch in any case, this is a gratuitous portability issue.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #29 from Jakub Jelinek jakub at gcc dot gnu.org 2011-11-28 15:10:00 UTC --- Created attachment 25937 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25937 gcc47-pr50237.patch Getting rid of the attribute constructor in libcpp/lex.c isn't that hard either.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #30 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-28 15:40:32 UTC --- Getting rid of the attribute constructor in libcpp/lex.c isn't that hard either. ... but doesn't help for the Go comparison failures. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-24 17:44:03 UTC --- This test uses the run-time test to check if .ctors and .init_array input sections can be mixed. Separate tests don't make much sense. Would you care to elaborate why checking the versions resp. features of the prerequisite components is not enough? Btw., what libc is required? I've successfully built and tested with --enable-init-fini-array on Solaris 11 (with no glibc in sight), provided I run a make bootstrap4 and ignore the comparison failure in stage3. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-23 15:27:22 UTC --- --- Comment #23 from H.J. Lu hjl.tools at gmail dot com 2011-11-22 18:03:09 UTC --- (In reply to comment #22) But this is the common case: you cannot expect or require the bootstrap compiler to use the same linker as you configure with. This is a bootstrap failure which is going to get us much noise if not fixed. Have you tried the patch in comment 18? Not yet, but I'm pretty sure it's wrong: In stage 1, the bootstrap compiler needn't be gcc, thus may not understand -B, so the result would be wrong even if you configure with gld 2.22. I don't understand why you go through so many contortions, full of unwarranted assumptions, when a simple check for gld = 2.22 (or 2.21.9x if absolutely necessary) would do. If other linkers gain the same support, the test can be augmented accordingly. I know this is ugly and real feature checks are the preferred way, but they are notoriously hard to get right portably, so many of them already go this route. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #25 from H.J. Lu hjl.tools at gmail dot com 2011-11-23 16:42:43 UTC --- (In reply to comment #24) --- Comment #23 from H.J. Lu hjl.tools at gmail dot com 2011-11-22 18:03:09 UTC --- (In reply to comment #22) But this is the common case: you cannot expect or require the bootstrap compiler to use the same linker as you configure with. This is a bootstrap failure which is going to get us much noise if not fixed. Have you tried the patch in comment 18? Not yet, but I'm pretty sure it's wrong: In stage 1, the bootstrap compiler needn't be gcc, thus may not understand -B, so the result would be wrong even if you configure with gld 2.22. I don't understand why you go through so many contortions, full of unwarranted assumptions, when a simple check for gld = 2.22 (or 2.21.9x if absolutely necessary) would do. If other linkers gain the same support, the test can be augmented accordingly. I know this is ugly and real feature checks are the preferred way, but they are notoriously hard to get right portably, so many of them already go this route. Checking linker version is inaccurate since this feature requires support in assembler, linker as well as libc. We can disable it by' default when 2 linkers are used.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-23 16:53:16 UTC --- Checking linker version is inaccurate since this feature requires support in assembler, linker as well as libc. We can disable it by' default when 2 linkers are used. Then why not check those separately and combine the result. It's certainly more reliable than the current guesswork. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #27 from H.J. Lu hjl.tools at gmail dot com 2011-11-23 17:15:58 UTC --- (In reply to comment #26) Checking linker version is inaccurate since this feature requires support in assembler, linker as well as libc. We can disable it by' default when 2 linkers are used. Then why not check those separately and combine the result. It's certainly more reliable than the current guesswork. This test uses the run-time test to check if .ctors and .init_array input sections can be mixed. Separate tests don't make much sense.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-22 17:21:38 UTC --- HJ, with binutils 2.22 now released, could you please work to get this fixed? IMO binutils releases need to work for bootstrapping gcc out of the box without any workarounds on the part of the installer. Thanks. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #21 from H.J. Lu hjl.tools at gmail dot com 2011-11-22 17:52:52 UTC --- (In reply to comment #20) HJ, with binutils 2.22 now released, could you please work to get this fixed? IMO binutils releases need to work for bootstrapping gcc out of the box without any workarounds on the part of the installer. There is not much I can do when there are 2 binutils used.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-11-22 17:55:15 UTC --- But this is the common case: you cannot expect or require the bootstrap compiler to use the same linker as you configure with. This is a bootstrap failure which is going to get us much noise if not fixed. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 --- Comment #23 from H.J. Lu hjl.tools at gmail dot com 2011-11-22 18:03:09 UTC --- (In reply to comment #22) But this is the common case: you cannot expect or require the bootstrap compiler to use the same linker as you configure with. This is a bootstrap failure which is going to get us much noise if not fixed. Have you tried the patch in comment 18?
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-suse-linux |x86_64-suse-linux, ||*-*-solaris2* Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-04 CC||ro at gcc dot gnu.org Host|x86_64-suse-linux |x86_64-suse-linux, ||*-*-solaris2* Ever Confirmed|0 |1 Build|x86_64-suse-linux |x86_64-suse-linux, ||*-*-solaris2* --- Comment #19 from Rainer Orth ro at gcc dot gnu.org 2011-10-04 13:54:59 UTC --- I observe exactly the same problem on Solaris 11/x86, especially with Go: gcc/go/unsafe.o differs gcc/go/lex.o differs gcc/go/runtime.o differs gcc/go/expressions.o differs gcc/go/dataflow.o differs gcc/go/ast-dump.o differs gcc/go/go-gcc.o differs gcc/go/import.o differs gcc/go/go.o differs gcc/go/export.o differs gcc/go/go-optimize.o differs gcc/go/go-dump.o differs gcc/go/import-archive.o differs gcc/go/gogo.o differs gcc/go/statements.o differs gcc/go/gogo-tree.o differs gcc/go/types.o differs gcc/go/parse.o differs The bootstrap compiler is gcc 4.4.2 configured with gas 2.19 and Sun ld, while I'm configuring with gas and gld 2.21.90 which have full .init_array/.fini_array support as required by H.J.'s check. Initially, I tried make bootstrap4, assuming that the comparison of stage2 and stage3 would be skipped in favour of the stage3/stage4 comparison (which works ok), but unfortunately this is not the case. Rainer
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2011-09/msg00223.htm |atches/2011-09/msg00668.htm |l |l --- Comment #18 from H.J. Lu hjl.tools at gmail dot com 2011-09-10 14:45:40 UTC --- The updated patch is posted at http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00668.html
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Summary|[4.7 regression] comparison |[4.7 regression] bootstrap |failure caused by |comparison failure for |HAVE_INITFINI_ARRAY check |libcpp/lex.o Severity|blocker |critical --- Comment #16 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-09-03 09:31:22 UTC --- The --disable-initfini-array workaround works fine so downgrading slightly.
[Bug bootstrap/50237] [4.7 regression] bootstrap comparison failure for libcpp/lex.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50237 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-09/msg00223.htm ||l --- Comment #17 from H.J. Lu hjl.tools at gmail dot com 2011-09-03 17:16:17 UTC --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00223.html
