[Bug bootstrap/57265] New: Bootstrap failure on sparc-sun-solaris2.10 in libquadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57265
Bug ID: 57265
Summary: Bootstrap failure on sparc-sun-solaris2.10 in
libquadmath
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: ahaas at airmail dot net
My builds have failed since April 15 when building 'libquadmath' after
completing the stage2/stage3 comparison. My last successful build was on April
14. The error below is taken from the 'config.log' file in the
'sparc-sun-solaris2.10/sparcv9/libquadmath' directory:
{ ... snip ... }
configure:3386: checking whether the C compiler works
configure:3395: ./a.out
ld.so.1: a.out: fatal: /export/home/arth/src/gcc-0512/./gcc/libgcc_s.so.1:
wrong
ELF class: ELFCLASS32
/export/home/arth/src/gcc.git/libquadmath/configure: line 3397: 11229 Killed
./$ac_file
configure:3399: $? = 137
configure:3406: error: in
`/export/home/arth/src/gcc-0512/sparc-sun-solaris2.10/
sparcv9/libquadmath':
configure:3410: error: cannot run C compiled programs.
A bit of git bisecting leads to this change:
commit 8aaed91dfc5f8fcd17fd6b61de3a6d68e59b5e1e
Author: ro ro@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Mon Apr 15 10:31:57 2013 +
Use -z ignore instead of --as-needed on Solaris
* configure.ac (gcc_cv_ld_as_needed): Set
gcc_cv_ld_as_needed_option, gcc_cv_no_as_needed_option.
Use -z ignore, -z record on *-*-solaris2*.
(HAVE_LD_AS_NEEDED): Update comment.
(LD_AS_NEEDED_OPTION, LD_NO_AS_NEEDED_OPTION): Define.
* configure: Regenerate.
* config.in: Regenerate.
* gcc.c (init_gcc_specs) [USE_LD_AS_NEEDED]: Use
LD_AS_NEEDED_OPTION, LD_NO_AS_NEEDED_OPTION.
* config/sol2.h [HAVE_LD_AS_NEEDED] (USE_LD_AS_NEEDED): Define.
* doc/tm.texi.in (USE_LD_AS_NEEDED): Allow for --as-needed
equivalents. Fix markup.
* doc/tm.texi: Regenerate.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@197964
138bc75d-0d04-0410-96
I'm able go get a successful build with the previous revision 197963, which is
'98c0d6572c62b325c1e8635df3d6b22003b83619' in my git checkout. In this
revision, the config.log contents from 'sparc-sun-solaris2.10/sparcv9' show
this test succeeding:
configure:3386: checking whether the C compiler works
configure:3395: ./a.out
configure:3399: $? = 0
configure:3414: result: yes
Thanks.
Art Haas
[Bug bootstrap/57265] Bootstrap failure on sparc-sun-solaris2.10 in libquadmath
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57265 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- -4 *** This bug has been marked as a duplicate of bug 57261 ***
New bootstrap failure on sparc-sun-solaris2.10
The latest set of patches to update the Sparc platform has resulted in a build failure in stage 1 of this mornings builds: gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H -I. -I. -I/export/home/arth/src/gcc.git/gcc -I/export/home/arth/src/gcc.git/gcc/. -I/export/home/arth/src/gcc.git/gcc/../include -I/export/home/arth/src/gcc.git/gcc/../libcpp/include -I/export/home/arth/local/include -I/export/home/arth/local/include -I/export/home/arth/local/include -I/export/home/arth/src/gcc.git/gcc/../libdecnumber -I/export/home/arth/src/gcc.git/gcc/../libdecnumber/dpd -I../libdecnumber -I. -I. -I/export/home/arth/src/gcc.git/gcc -I/export/home/arth/src/gcc.git/gcc/. -I/export/home/arth/src/gcc.git/gcc/../include -I/export/home/arth/src/gcc.git/gcc/../libcpp/include -I/export/home/arth/local/include -I/export/home/arth/local/include -I/export/home/arth/local/include -I/export/home/arth/src/gcc.git/gcc/../libdecnumber -I/export/home/arth/src/gcc.git/gcc/../libdecnumber/dpd -I../libdecnumber /export/home/arth/src/gcc.git/gcc/config/sol2-stubs.c /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c: In function 'sparc_fold_builtin': /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9727:2: error: duplicate case value /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9726:2: error: previously used here /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9728:2: error: duplicate case value /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9726:2: error: previously used here /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9729:2: error: duplicate case value /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9726:2: error: previously used here /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9730:2: error: duplicate case value /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9726:2: error: previously used here /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9731:2: error: duplicate case value /export/home/arth/src/gcc.git/gcc/config/sparc/sparc.c:9726:2: error: previously used here gmake[3]: *** [sparc.o] Error 1 I'd mailed about bootstrap failures last week, and in those the build was failing at the stage2/stage three comparison. One question in the reply to my earlier mail was what version of GNU as/ld I'm, and there both from binutils-2.21, built on December 15 last year and working fine all this year: $ as --version GNU assembler (GNU Binutils) 2.21 Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `sparc-sun-solaris2.10'. $ ld --version GNU ld (GNU Binutils) 2.21 Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. I tried to build using the Solaris provided GNU as and Sun ld, but the build failed when trying to build an 'lto' library. I've unfortunately removed the build log so I can't copy the error, but it looked to be due to a path issue where a '.libs' directory did not exist. Here's the configuration for my last successful GCC build early last month: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.7.0/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /export/home/arth/src/gcc.git/configure --prefix=/export/home/arth/local --enable-languages=c,c++,objc --disable-nls --with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local --with-mpc=/export/home/arth/local --enable-checking=release --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no --with-cpu=ultrasparc3 --with-tune=ultrasparc3 Thread model: posix gcc version 4.7.0 20110906 (experimental) [master revision bdc818b:c562c54:dfb98d7502700782f4a1a4e04357e46fd90784fe] (GCC) Thanks to everyone working on GCC. Art Haas
Re: Bootstrap failure on sparc-sun-solaris2.10
Art Haas ah...@impactweather.com writes: I've had no success lately getting GCC to bootstrap successfully. My last successful bootstrap was on September 6; my builds on September 7 through today all end with a comparison failure. Here's the end of my build log: gmake[2]: Entering directory `/export/home/arth/src/gcc-0929' gmake[3]: Entering directory `/export/home/arth/src/gcc-0929' rm -f stage_current gmake[3]: Leaving directory `/export/home/arth/src/gcc-0929' 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! libdecnumber/decNumber.o differs gmake[2]: *** [compare] Error 1 gmake[2]: Leaving directory `/export/home/arth/src/gcc-0929' gmake[1]: *** [stage3-bubble] Error 2 gmake[1]: Leaving directory `/export/home/arth/src/gcc-0929' gmake: *** [bootstrap-lean] Error 2 I didn't have an issue bootstrapping mainline yesterday on Solaris 8 to 11. My last successful build was configured like so: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.7.0/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /export/home/arth/src/gcc.git/configure --prefix=/export/home/arth/local --enable-languages=c,c++,objc --disable-nls --with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local --with-mpc=/export/home/arth/local --enable-checking=release --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no --with-cpu=ultrasparc3 --with-tune=ultrasparc3 Which version of gas and gld are you using? I'd stay away from gld, especially on SPARC. Please also try a bootstrap without the --with-cpu and --with-tune options to see if that makes a difference. I've seen numerous Sparc related patch land after my last successful build, so I'm guessing the issue is Solaris specific. Anyone else who builds on this platform seeing similar problems? If the problem persists even with my suggested changes, please file a bootstrap PR and Cc it to Eric and Dave M. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Bootstrap failure on sparc-sun-solaris2.10
I've had no success lately getting GCC to bootstrap successfully. My last successful bootstrap was on September 6; my builds on September 7 through today all end with a comparison failure. Here's the end of my build log: gmake[2]: Entering directory `/export/home/arth/src/gcc-0929' gmake[3]: Entering directory `/export/home/arth/src/gcc-0929' rm -f stage_current gmake[3]: Leaving directory `/export/home/arth/src/gcc-0929' 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! libdecnumber/decNumber.o differs gmake[2]: *** [compare] Error 1 gmake[2]: Leaving directory `/export/home/arth/src/gcc-0929' gmake[1]: *** [stage3-bubble] Error 2 gmake[1]: Leaving directory `/export/home/arth/src/gcc-0929' gmake: *** [bootstrap-lean] Error 2 My last successful build was configured like so: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/export/home/arth/local/libexec/gcc/sparc-sun-solaris2.10/4.7.0/lto-wrapper Target: sparc-sun-solaris2.10 Configured with: /export/home/arth/src/gcc.git/configure --prefix=/export/home/arth/local --enable-languages=c,c++,objc --disable-nls --with-gmp=/export/home/arth/local --with-mpfr=/export/home/arth/local --with-mpc=/export/home/arth/local --enable-checking=release --enable-threads --with-gnu-as --with-as=/export/home/arth/local/bin/as --with-gnu-ld --with-ld=/export/home/arth/local/bin/ld --enable-libstdcxx-pch=no --with-cpu=ultrasparc3 --with-tune=ultrasparc3 Thread model: posix gcc version 4.7.0 20110906 (experimental) [master revision bdc818b:c562c54:dfb98d7502700782f4a1a4e04357e46fd90784fe] (GCC) $ I've seen numerous Sparc related patch land after my last successful build, so I'm guessing the issue is Solaris specific. Anyone else who builds on this platform seeing similar problems? Art Haas
Re: Bootstrap failure on sparc-sun-solaris2.10
Hi Art, This morning's build on sparc-sun-solaris2.10 failed for me; the error message in 'stage_2' is below: options.c:753:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:753:3: error: (near initialization for 'global_options_init.x_sparc_cpu_and_features') [-Werror=c++-compat] options.c:755:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:755:3: error: (near initialization for 'global_options_init.x_sparc_cpu') [-Werror=c++-compat] cc1: all warnings being treated as errors My build on Friday worked, so the likely culprit is this change from today: 2011-03-28 Joseph Myers jos...@codesourcery.com * config/sparc/sparc-opts.h: New. * config/sparc/sparc.c (sparc_handle_option, sparc_select, sparc_cpu, fpu_option_set, TARGET_HANDLE_OPTION): Remove. (sparc_option_override): Store processor_type enumeration rather than string in cpu_default. Remove name and enumeration from cpu_table. Directly default -mcpu then default -mtune from -mcpu without using sparc_select. Use target_flags_explicit instead of fpu_option_set. * config/sparc/sparc.h (enum processor_type): Move to sparc-opts.h. (sparc_cpu, struct sparc_cpu_select, sparc_select): Remove. * config/sparc/sparc.opt (config/sparc/sparc-opts.h): New HeaderInclude entry. (mcpu=, mtune=): Use Var and Enum. (sparc_processor_type): New Enum and EnumValue entries. The relevant lines of the auto-generated 'options.c' file look like this: 752: 0, /* sparc_cmodel_string */ 753: 0, /* sparc_cpu_and_features */ 754: 0, /* sparc_std_struct_return */ 755: 0, /* sparc_cpu */ 756: 0, /* asm_file_name */ I've just run into this myself and filed PR bootstrap/48337 for the issue. In general, you should do so yourself and Cc: the maintainers and patch author. It's a better way to get attention than just posting to the gcc list. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Bootstrap failure on sparc-sun-solaris2.10
Hi. This morning's build on sparc-sun-solaris2.10 failed for me; the error message in 'stage_2' is below: options.c:753:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:753:3: error: (near initialization for 'global_options_init.x_sparc_cpu_and_features') [-Werror=c++-compat] options.c:755:3: error: enum conversion in initialization is invalid in C++ [-Werror=c++-compat] options.c:755:3: error: (near initialization for 'global_options_init.x_sparc_cpu') [-Werror=c++-compat] cc1: all warnings being treated as errors My build on Friday worked, so the likely culprit is this change from today: 2011-03-28 Joseph Myers jos...@codesourcery.com * config/sparc/sparc-opts.h: New. * config/sparc/sparc.c (sparc_handle_option, sparc_select, sparc_cpu, fpu_option_set, TARGET_HANDLE_OPTION): Remove. (sparc_option_override): Store processor_type enumeration rather than string in cpu_default. Remove name and enumeration from cpu_table. Directly default -mcpu then default -mtune from -mcpu without using sparc_select. Use target_flags_explicit instead of fpu_option_set. * config/sparc/sparc.h (enum processor_type): Move to sparc-opts.h. (sparc_cpu, struct sparc_cpu_select, sparc_select): Remove. * config/sparc/sparc.opt (config/sparc/sparc-opts.h): New HeaderInclude entry. (mcpu=, mtune=): Use Var and Enum. (sparc_processor_type): New Enum and EnumValue entries. The relevant lines of the auto-generated 'options.c' file look like this: 752: 0, /* sparc_cmodel_string */ 753: 0, /* sparc_cpu_and_features */ 754: 0, /* sparc_std_struct_return */ 755: 0, /* sparc_cpu */ 756: 0, /* asm_file_name */ Thanks, as always, to everyone working on GCC. Art Haas
Bootstrap failure in sparc-sun-solaris2.10
Hi. Even with the patch listed in the bug report below my bootstrap would still fail when the compiler tries to build libgcc. The bug report for the bootstrap failure is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37424 The build failed while building libgcc - the code would trip up on an assert in haifa-sched.c, similar to the message posted here, though now the assert is on line 2318: http://gcc.gnu.org/ml/gcc/2008-09/msg00106.html Applying the patch Adam created and posted in the message below resolved the issue and the compiler successfully bootstrapped: http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html There was one reply to this message; I don't know if the patch is being reworked or been formally submitted yet, but it did fix my build. Art Haas
Re: Bootstrap failure in sparc-sun-solaris2.10
Even with the patch listed in the bug report below my bootstrap would still fail when the compiler tries to build libgcc. The bug report for the bootstrap failure is here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37424 That patch is not the fix, this is explained in the audit trail. The fix is 2008-09-11 Jeff Law [EMAIL PROTECTED] * reload1.c (alter_reg): Undo the BYTE_BIG_ENDIAN correction performed by assign_stack_local on the IRA path for stack slot sharing as well as the non-IRA path. The build failed while building libgcc - the code would trip up on an assert in haifa-sched.c, similar to the message posted here, though now the assert is on line 2318: http://gcc.gnu.org/ml/gcc/2008-09/msg00106.html Applying the patch Adam created and posted in the message below resolved the issue and the compiler successfully bootstrapped: http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html Thanks for reporting this. I now can close PR 37424. There was one reply to this message; I don't know if the patch is being reworked or been formally submitted yet, but it did fix my build. OK, I'll take a look. -- Eric Botcazou
Re: Bootstrap failure in sparc-sun-solaris2.10
Eric Botcazou [EMAIL PROTECTED] writes: Applying the patch Adam created and posted in the message below resolved the issue and the compiler successfully bootstrapped: http://gcc.gnu.org/ml/gcc/2008-09/msg00139.html Thanks for reporting this. I now can close PR 37424. There was one reply to this message; I don't know if the patch is being reworked or been formally submitted yet, but it did fix my build. OK, I'll take a look. Yes it was formally submitted here, no review so far: http://gcc.gnu.org/ml/gcc-patches/2008-09/msg00574.html Adam
Re: Bootstrap failure on sparc-sun-solaris2.10
Eric Botcazou writes: Confirmed (on Solaris 9). Would you mind opening a PR? There is already one for Linux (37344) but the failure is a little different. Thanks in advance. Sure, done: PR bootstrap/37424. Rainer
Re: Bootstrap failure on sparc-sun-solaris2.10
From: Rainer Orth [EMAIL PROTECTED] Date: Mon, 8 Sep 2008 17:18:50 +0200 (MEST) Eric Botcazou writes: Confirmed (on Solaris 9). Would you mind opening a PR? There is already one for Linux (37344) but the failure is a little different. Thanks in advance. Sure, done: PR bootstrap/37424. BTW, I'm also seeing the sparc-*-linux failure, and it seems the compiler is outputting an unaligned memory access somehow.
Re: Bootstrap failure on sparc-sun-solaris2.10
When I tried mainline bootstrap on sparc-sun-solaris2.11 as of 20080903 (rev 139939), I get a configure failure in stage2 libgcc: checking for suffix of object files... configure: error: in `/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/sparc-sun-solaris2.11/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. and config.log reveals: configure:2590: checking for suffix of object files configure:2611: /vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/./gcc/xgcc -B/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -c -g -O2conftest.c 5 conftest.c:12: internal compiler error: Bus Error Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Confirmed (on Solaris 9). Would you mind opening a PR? There is already one for Linux (37344) but the failure is a little different. Thanks in advance. -- Eric Botcazou
Re: Bootstrap failure on sparc-sun-solaris2.10
H.J. Lu wrote: On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler [EMAIL PROTECTED] wrote: H.J. Lu wrote: It is a temporary branch, branches/ira-merge, to track IRA related problems. Same issue. Does trunk bootstrap with revision 139589? No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042] (GCC) If trunk was broken at revision 139589, your problem isn't related to IRA since IRA was merged at revision 139590. Sorry, misread the above. - 139589 bootstrap ok and tested - 139590 bootstrap nok. Andreas
Re: Bootstrap failure on sparc-sun-solaris2.10
On Sat, Sep 6, 2008 at 8:30 AM, Andreas Tobler [EMAIL PROTECTED] wrote: H.J. Lu wrote: On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler [EMAIL PROTECTED] wrote: H.J. Lu wrote: It is a temporary branch, branches/ira-merge, to track IRA related problems. Same issue. Does trunk bootstrap with revision 139589? No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042] (GCC) If trunk was broken at revision 139589, your problem isn't related to IRA since IRA was merged at revision 139590. Sorry, misread the above. - 139589 bootstrap ok and tested - 139590 bootstrap nok. I suggest you open a bug report saying that IRA breaks Sparc bootstrap. -- H.J.
Bootstrap failure on sparc-sun-solaris2.10
Hi. My build attempts on sparc-sun-solaris2.10 haven't been working well since the IRA merge, but given the scope of that change and the fixes applied since the merge I'm certain the build will be in good shape soon. This morning's build attempt failed while compiling libgcc: /export/home/arth/src/gcc.git/libgcc/../gcc/libgcc2.c: In function '__moddi3': /export/home/arth/src/gcc.git/libgcc/../gcc/libgcc2.c:1125: internal compiler error: in choose_ready, at haifa-sched.c:2309 A similar failure in the haifa-sched.c code was sent to the mailing list earlier today: http://gcc.gnu.org/ml/gcc/2008-09/msg00106.html Art Haas
Re: Bootstrap failure on sparc-sun-solaris2.10
Art Haas [EMAIL PROTECTED] writes:
My build attempts on sparc-sun-solaris2.10 haven't been working well
since the IRA merge, but given the scope of that change and the fixes
applied since the merge I'm certain the build will be in good shape
soon.
This morning's build attempt failed while compiling libgcc:
/export/home/arth/src/gcc.git/libgcc/../gcc/libgcc2.c: In function
'__moddi3':
/export/home/arth/src/gcc.git/libgcc/../gcc/libgcc2.c:1125: internal
compiler error: in choose_ready, at haifa-sched.c:2309
When I tried mainline bootstrap on sparc-sun-solaris2.11 as of 20080903
(rev 139939), I get a configure failure in stage2 libgcc:
checking for suffix of object files... configure: error: in
`/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/sparc-sun-solaris2.11/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
and config.log reveals:
configure:2590: checking for suffix of object files
configure:2611: /vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/./gcc/xgcc
-B/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/./gcc/
-B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/
-isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem
/vol/gcc/sparc-sun-solaris2.11/sys-include -c -g -O2conftest.c 5
conftest.c:12: internal compiler error: Bus Error
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
configure:2614: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2627: error: in
`/vol/gccsrc/obj/gcc-4.4.0-20080903/11-gcc/sparc-sun-solaris2.11/libgcc':
configure:2629: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Running cc1 -O2 conftest.i gives
Program received signal SIGSEGV, Segmentation fault.
grokdeclarator (declarator=0x8bf240, declspecs=0x8bf1e8, decl_context=NORMAL,
initialized=1 '\001', width=0x0, decl_attrs=0xffbff454,
deprecated_state=DEPRECATED_NORMAL) at /vol/gcc/src/gcc-dist/gcc/c-decl.c:4194
(gdb) where
#0 grokdeclarator (declarator=0x8bf240, declspecs=0x8bf1e8,
decl_context=NORMAL, initialized=1 '\001', width=0x0, decl_attrs=0xffbff454,
deprecated_state=DEPRECATED_NORMAL) at /vol/gcc/src/gcc-dist/gcc/c-decl.c:4194
#1 0x000b3340 in start_function (declspecs=0x8bf1e8, declarator=0x8bf240,
attributes=0x0) at /vol/gcc/src/gcc-dist/gcc/c-decl.c:6096
#2 0x0010f964 in c_parser_declaration_or_fndef (parser=0xff01d720, fndef_ok=1
'\001', empty_ok=value optimized out, nested=0 '\0', start_attr_ok=value
optimized out) at /vol/gcc/src/gcc-dist/gcc/c-parser.c:1278
#3 0x00114574 in c_parse_file () at /vol/gcc/src/gcc-dist/gcc/c-parser.c:979
#4 0x000f7470 in c_common_parse_file (set_yydebug=0) at
/vol/gcc/src/gcc-dist/gcc/c-opts.c:1239
#5 0x003c40c0 in toplev_main (argc=value optimized out, argv=value
optimized out) at /vol/gcc/src/gcc-dist/gcc/toplev.c:968
#6 0x00097e54 in _start ()
Looks like a code generation bug to me. I'll try to start a reghunt asap.
Btw., i386-pc-solaris2.10 is also broken for me, this time while
configuring stage3 libgcc ;-( Same is true for alpha-dec-osf5.1b and
mips-sgi-irix6.5, so all four of my platforms got broken during the last
for weeks while I was on vacation.
Rainer
--
-
Rainer Orth, Faculty of Technology, Bielefeld University
Re: Bootstrap failure on sparc-sun-solaris2.10
Rainer Orth wrote: Looks like a code generation bug to me. I'll try to start a reghunt asap. Start around the 25/26th of August. IRA. Since then it is borked. Andreas
Re: Bootstrap failure on sparc-sun-solaris2.10
H.J. Lu wrote: On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler [EMAIL PROTECTED] wrote: Rainer Orth wrote: Looks like a code generation bug to me. I'll try to start a reghunt asap. Start around the 25/26th of August. IRA. Since then it is borked. Can you try ira-merge branch? It has all IRA bug fixes without non-IRA changes. How is it named? ira-merge? If, I can't find it on http://gcc.gnu.org/svn.html. Thanks, Andreas
Re: Bootstrap failure on sparc-sun-solaris2.10
On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler [EMAIL PROTECTED] wrote: H.J. Lu wrote: On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler [EMAIL PROTECTED] wrote: Rainer Orth wrote: Looks like a code generation bug to me. I'll try to start a reghunt asap. Start around the 25/26th of August. IRA. Since then it is borked. Can you try ira-merge branch? It has all IRA bug fixes without non-IRA changes. How is it named? ira-merge? If, I can't find it on http://gcc.gnu.org/svn.html. It is a temporary branch, branches/ira-merge, to track IRA related problems. -- H.J.
Re: Bootstrap failure on sparc-sun-solaris2.10
H.J. Lu wrote: Can you try ira-merge branch? It has all IRA bug fixes without non-IRA changes. How is it named? ira-merge? If, I can't find it on http://gcc.gnu.org/svn.html. It is a temporary branch, branches/ira-merge, to track IRA related problems. Thanks, co right now. Andreas
Re: Bootstrap failure on sparc-sun-solaris2.10
H.J. Lu wrote: On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler [EMAIL PROTECTED] wrote: H.J. Lu wrote: On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler [EMAIL PROTECTED] wrote: Rainer Orth wrote: Looks like a code generation bug to me. I'll try to start a reghunt asap. Start around the 25/26th of August. IRA. Since then it is borked. Can you try ira-merge branch? It has all IRA bug fixes without non-IRA changes. How is it named? ira-merge? If, I can't find it on http://gcc.gnu.org/svn.html. It is a temporary branch, branches/ira-merge, to track IRA related problems. Same issue. Andreas
Re: Bootstrap failure on sparc-sun-solaris2.10
On Fri, Sep 5, 2008 at 2:43 PM, Andreas Tobler [EMAIL PROTECTED] wrote: H.J. Lu wrote: On Fri, Sep 5, 2008 at 12:36 PM, Andreas Tobler [EMAIL PROTECTED] wrote: H.J. Lu wrote: On Fri, Sep 5, 2008 at 12:15 PM, Andreas Tobler [EMAIL PROTECTED] wrote: Rainer Orth wrote: Looks like a code generation bug to me. I'll try to start a reghunt asap. Start around the 25/26th of August. IRA. Since then it is borked. Can you try ira-merge branch? It has all IRA bug fixes without non-IRA changes. How is it named? ira-merge? If, I can't find it on http://gcc.gnu.org/svn.html. It is a temporary branch, branches/ira-merge, to track IRA related problems. Same issue. Does trunk bootstrap with revision 139589? -- H.J.
Re: Bootstrap failure on sparc-sun-solaris2.10
H.J. Lu wrote: It is a temporary branch, branches/ira-merge, to track IRA related problems. Same issue. Does trunk bootstrap with revision 139589? No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042] (GCC) Andreas
Re: Bootstrap failure on sparc-sun-solaris2.10
On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler [EMAIL PROTECTED] wrote: H.J. Lu wrote: It is a temporary branch, branches/ira-merge, to track IRA related problems. Same issue. Does trunk bootstrap with revision 139589? No, gcc version 4.4.0 20080905 (experimental) [trunk revision 140042] (GCC) If trunk was broken at revision 139589, your problem isn't related to IRA since IRA was merged at revision 139590. -- H.J.
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
2007/9/10, John David Anglin [EMAIL PROTECTED]: I succeed past this failure if I revert Zdenek's iv-opts patch (r128272). Same here. The failure also occurs on all hppa targets. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) here too, on sparc/sparc64 linux systems: checking whether ln -s works... yes checking for sparc64-unknown-linux-gnu-gcc... /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage2-target-libgcc] Error 1 make[2]: Leaving directory `/usr/local/src/trunk/objdir' -- Cheers, /ChJ
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
2007/9/10, John David Anglin [EMAIL PROTECTED]: I succeed past this failure if I revert Zdenek's iv-opts patch (r128272). Same here. The failure also occurs on all hppa targets. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602) here too, on sparc/sparc64 linux systems: checking whether ln -s works... yes checking for sparc64-unknown-linux-gnu-gcc... /usr/local/src/trunk/objdir/./gcc/xgcc -B/usr/local/src/trunk/objdir/./gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. make[2]: *** [configure-stage2-target-libgcc] Error 1 make[2]: Leaving directory `/usr/local/src/trunk/objdir' -- Cheers, /ChJ
Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
Rats, I'm getting another bootstap failure on sparc-sun-solaris2.10.
This time it happens in stage2 building libgcc. What happens is that
when it runs configure for stage2 libgcc, I get:
checking for suffix of object files...
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
whereupon in config.log I see:
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
The stage2 gcc cannot compile this simple program. The stage1
compiler can, so looks like stage2 was miscompiled. Running it under
gdb doesn't yield any useful info.
This is fairly recent as I got a successful testresult here:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00402.html
The top of the gcc/ChangeLog from the working checkout was:
2007-09-07 Sterling Augustine [EMAIL PROTECTED]
* config/xtensa/lib2funcs.S (__xtensa_sync_caches): Use an ISYNC even
if there is no i-cache.
Is anyone else having a similar problem?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
On Sun, 9 Sep 2007, David Edelsohn wrote: Kaveh The stage2 gcc cannot compile this simple program. The stage1 Kaveh compiler can, so looks like stage2 was miscompiled. Running it under Kaveh gdb doesn't yield any useful info. I am seeing the same failure on AIX. The SEGV on AIX is in postreload.c and if I recompile that file without optimization, the config test succeeds. David Ditto. Program received signal SIGSEGV, Segmentation fault. 0x002cf780 in reload_combine_note_store (dst=0xff0b90e0, set=value optimized out, data=0x0) at ../../egcc-SVN20070909/gcc/postreload.c:1018 1018 reg_state[i].store_ruid = reload_combine_ruid; (gdb) Any luck figuring out which patch broke it? --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
Kaveh R GHAZI writes: Kaveh Program received signal SIGSEGV, Segmentation fault. Kaveh 0x002cf780 in reload_combine_note_store (dst=0xff0b90e0, set=value Kaveh optimized out, data=0x0) Kaveh at ../../egcc-SVN20070909/gcc/postreload.c:1018 Kaveh 1018 reg_state[i].store_ruid = reload_combine_ruid; Kaveh (gdb) That is the exact same failure and line for AIX. Apparently all Big Endian targets are affected. Kaveh Any luck figuring out which patch broke it? Not yet. Candidates include: r128239 (honza's simple dce/addressing passes) and then r128272 (the iv-opt patch), and Richi's sccvn patch. David
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
I succeed past this failure if I revert Zdenek's iv-opts patch (r128272). David
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
I succeed past this failure if I revert Zdenek's iv-opts patch (r128272). Same here. The failure also occurs on all hppa targets. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
Rats, I'm getting another bootstap failure on sparc-sun-solaris2.10.
This time it happens in stage2 building libgcc. What happens is that
when it runs configure for stage2 libgcc, I get:
checking for suffix of object files...
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
whereupon in config.log I see:
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
The stage2 gcc cannot compile this simple program. The stage1
compiler can, so looks like stage2 was miscompiled. Running it under
gdb doesn't yield any useful info.
This is fairly recent as I got a successful testresult here:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00402.html
The top of the gcc/ChangeLog from the working checkout was:
2007-09-07 Sterling Augustine [EMAIL PROTECTED]
* config/xtensa/lib2funcs.S (__xtensa_sync_caches): Use an ISYNC even
if there is no i-cache.
Is anyone else having a similar problem?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
Kaveh R GHAZI writes:
Kaveh Rats, I'm getting another bootstap failure on sparc-sun-solaris2.10.
Kaveh This time it happens in stage2 building libgcc. What happens is that
Kaveh when it runs configure for stage2 libgcc, I get:
Kaveh checking for suffix of object files...
Kaveh configure: error: cannot compute suffix of object files: cannot compile
Kaveh See `config.log' for more details.
Kaveh whereupon in config.log I see:
Kaveh configure: failed program was:
Kaveh | /* confdefs.h. */
Kaveh |
Kaveh | #define PACKAGE_NAME GNU C Runtime Library
Kaveh | #define PACKAGE_TARNAME libgcc
Kaveh | #define PACKAGE_VERSION 1.0
Kaveh | #define PACKAGE_STRING GNU C Runtime Library 1.0
Kaveh | #define PACKAGE_BUGREPORT
Kaveh | /* end confdefs.h. */
Kaveh |
Kaveh | int
Kaveh | main ()
Kaveh | {
Kaveh |
Kaveh | ;
Kaveh | return 0;
Kaveh | }
Kaveh The stage2 gcc cannot compile this simple program. The stage1
Kaveh compiler can, so looks like stage2 was miscompiled. Running it under
Kaveh gdb doesn't yield any useful info.
I am seeing the same failure on AIX. The SEGV on AIX is in
postreload.c and if I recompile that file without optimization, the config
test succeeds.
David
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
On Sun, 9 Sep 2007, David Edelsohn wrote: Kaveh The stage2 gcc cannot compile this simple program. The stage1 Kaveh compiler can, so looks like stage2 was miscompiled. Running it under Kaveh gdb doesn't yield any useful info. I am seeing the same failure on AIX. The SEGV on AIX is in postreload.c and if I recompile that file without optimization, the config test succeeds. David Ditto. Program received signal SIGSEGV, Segmentation fault. 0x002cf780 in reload_combine_note_store (dst=0xff0b90e0, set=value optimized out, data=0x0) at ../../egcc-SVN20070909/gcc/postreload.c:1018 1018 reg_state[i].store_ruid = reload_combine_ruid; (gdb) Any luck figuring out which patch broke it? --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
Kaveh R GHAZI writes: Kaveh Program received signal SIGSEGV, Segmentation fault. Kaveh 0x002cf780 in reload_combine_note_store (dst=0xff0b90e0, set=value Kaveh optimized out, data=0x0) Kaveh at ../../egcc-SVN20070909/gcc/postreload.c:1018 Kaveh 1018 reg_state[i].store_ruid = reload_combine_ruid; Kaveh (gdb) That is the exact same failure and line for AIX. Apparently all Big Endian targets are affected. Kaveh Any luck figuring out which patch broke it? Not yet. Candidates include: r128239 (honza's simple dce/addressing passes) and then r128272 (the iv-opt patch), and Richi's sccvn patch. David
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
I succeed past this failure if I revert Zdenek's iv-opts patch (r128272). David
Re: Another BOOTSTRAP failure on sparc-sun-solaris2.10, stage2 miscompiled
I succeed past this failure if I revert Zdenek's iv-opts patch (r128272). Same here. The failure also occurs on all hppa targets. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
2007/9/6, Kaveh R. GHAZI [EMAIL PROTECTED]: (Sorry, first one bounced from gcc@ because it was over 400k) Hi Jan, On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2 complaining several times about rtl sharing. I've included four .i files for modules that ICEed during stage2, and the cc1 invocations below. Would you please take a look? Thanks, --Kaveh FWIW, I get a similar problem on sparc/sparc64 linux. -- Cheers, /ChJ
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
2007/9/7, Christian Joensson [EMAIL PROTECTED]:
2007/9/6, Kaveh R. GHAZI [EMAIL PROTECTED]:
(Sorry, first one bounced from gcc@ because it was over 400k)
Hi Jan,
On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
complaining several times about rtl sharing. I've included four .i files
for modules that ICEed during stage2, and the cc1 invocations below.
Would you please take a look?
Thanks,
--Kaveh
FWIW, I get a similar problem on sparc/sparc64 linux.
maybe I should have included this before:
/usr/local/src/trunk/objdir/./prev-gcc/xgcc
-B/usr/local/src/trunk/objdir/./prev-gcc/
-B/usr/local/sparc64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W
-Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc
-I../../gcc/gcc/. -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I/usr/local/gmp-mpfr/include
-I/usr/local/gmp-mpfr/include -I../../gcc/gcc/../libdecnumber
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber
../../gcc/gcc/c-format.c -o c-format.o
../../gcc/gcc/c-format.c: In function 'check_format_string':
../../gcc/gcc/c-format.c:150: error: invalid rtl sharing found in the insn
(insn 341 337 342 ../../gcc/gcc/c-format.c:145 (sequence [
(jump_insn 338 337 216 (return) 394 {*return_internal}
(expr_list:REG_BR_PRED (const_int 12 [0xc])
(nil)))
(insn 216 338 342 (set (reg:QI 24 %i0 [orig:111 D.17641 ] [111])
(const_int 0 [0x0])) 47 {*movqi_insn}
(expr_list:REG_EQUAL (const_int 0 [0x0])
(nil)))
]) -1 (nil))
../../gcc/gcc/c-format.c:150: error: shared rtx
(insn 216 338 342 (set (reg:QI 24 %i0 [orig:111 D.17641 ] [111])
(const_int 0 [0x0])) 47 {*movqi_insn} (expr_list:REG_EQUAL
(const_int 0 [0x0])
(nil)))
../../gcc/gcc/c-format.c:150: internal compiler error: internal
consistency failure
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [c-format.o] Error 1
make[3]: Leaving directory `/usr/local/src/trunk/objdir/gcc'
make[2]: *** [all-stage3-gcc] Error 2
make[2]: Leaving directory `/usr/local/src/trunk/objdir'
make[1]: *** [stage3-bubble] Error 2
make[1]: Leaving directory `/usr/local/src/trunk/objdir'
make: *** [all] Error 2
This is using Fri Sep 7 05:44:14 UTC 2007 (revision 128228)
--
Cheers,
/ChJ
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
On Thu, 6 Sep 2007, Jan Hubicka wrote:
Ah, I see.
The attached patch seems to work on my testcase too.
Honza
Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3863,17 +3863,6 @@ dbr_schedule (rtx first)
relax_delay_slots (first);
}
- /* Delete any USE insns made by update_block; subsequent passes don't need
- them or know how to deal with them. */
- for (insn = first; insn; insn = next)
-{
- next = NEXT_INSN (insn);
-
- if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
-INSN_P (XEXP (PATTERN (insn), 0)))
- next = delete_related_insns (insn);
-}
-
/* If we made an end of function label, indicate that it is now
safe to delete it by undoing our prior adjustment to LABEL_NUSES.
If it is now unused, delete it. */
@@ -3885,6 +3874,17 @@ dbr_schedule (rtx first)
make_return_insns (first);
#endif
+ /* Delete any USE insns made by update_block; subsequent passes don't need
+ them or know how to deal with them. */
+ for (insn = first; insn; insn = next)
+{
+ next = NEXT_INSN (insn);
+
+ if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
+INSN_P (XEXP (PATTERN (insn), 0)))
+ next = delete_related_insns (insn);
+}
+
obstack_free (unfilled_slots_obstack, unfilled_firstobj);
/* It is not clear why the line below is needed, but it does seem to be.
*/
This second patch also allows bootstrap to complete on my sparc box.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
This second patch also allows bootstrap to complete on my sparc box. Thanks for testing and good news, I will commit the patch Honza Thanks, --Kaveh -- Kaveh R. Ghazi[EMAIL PROTECTED]
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Kaveh R. GHAZI wrote: (Sorry, first one bounced from gcc@ because it was over 400k) Hi Jan, On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2 complaining several times about rtl sharing. I've included four .i files for modules that ICEed during stage2, and the cc1 invocations below. Would you please take a look? Jan proposed the below patch. I successfully tested it and I'm testing now. Regards, Andreas Index: reorg.c === --- reorg.c (revision 128181) +++ reorg.c (working copy) @@ -3991,6 +3991,9 @@ if (GET_CODE (pat) == SEQUENCE) insn = XVECEXP (pat, 0, 0); } + if (INSN_P (insn) GET_CODE (PATTERN (insn)) == USE + INSN_P (XEXP (PATTERN (insn), 0))) + delete_insn (insn); if (!JUMP_P (insn)) continue;
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
(Sorry, first one bounced from gcc@ because it was over 400k)
Hi Jan,
On sparc-sun-solaris2.10, I'm getting new bootstrap failures in stage2
complaining several times about rtl sharing. I've included four .i files
for modules that ICEed during stage2, and the cc1 invocations below.
Would you please take a look?
Hi,
I already have fix for this just waiting for Andreas Tobler to verify
that it does what expected. If you could give it a try, it would be
nice.
The problem is
/* Called when INSN is being moved from a location near the target of a jump.
We leave a marker of the form (use (INSN)) immediately in front
of WHERE for mark_target_live_regs. These markers will be deleted when
reorg finishes.
We used to try to update the live status of registers if WHERE is at
the start of a basic block, but that can't work since we may remove a
BARRIER in relax_delay_slots. */
static void
update_block (rtx insn, rtx where)
{
/* Ignore if this was in a delay slot and it came from the target of
a branch. */
if (INSN_FROM_TARGET_P (insn))
return;
emit_insn_before (gen_rtx_USE (VOIDmode, insn), where);
/* INSN might be making a value live in a block where it didn't use to
be. So recompute liveness information for this block. */
incr_ticks_for_insn (insn);
}
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
Honza
Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3991,6 +3991,9 @@ dbr_schedule (rtx first)
if (GET_CODE (pat) == SEQUENCE)
insn = XVECEXP (pat, 0, 0);
}
+ if (INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
+ INSN_P (XEXP (PATTERN (insn), 0)))
+ delete_insn (insn);
if (!JUMP_P (insn))
continue;
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Hi,
I already have fix for this just waiting for Andreas Tobler to verify
that it does what expected. If you could give it a try, it would be
nice.
The problem is
/* Called when INSN is being moved from a location near the target of a jump.
We leave a marker of the form (use (INSN)) immediately in front
of WHERE for mark_target_live_regs. These markers will be deleted when
reorg finishes.
We used to try to update the live status of registers if WHERE is at
the start of a basic block, but that can't work since we may remove a
BARRIER in relax_delay_slots. */
static void
update_block (rtx insn, rtx where)
{
/* Ignore if this was in a delay slot and it came from the target of
a branch. */
if (INSN_FROM_TARGET_P (insn))
return;
emit_insn_before (gen_rtx_USE (VOIDmode, insn), where);
/* INSN might be making a value live in a block where it didn't use to
be. So recompute liveness information for this block. */
incr_ticks_for_insn (insn);
}
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
Honza
Since patch seems to work for Andreas, would it be OK?
* recog.c (dbr_schedule): Remove placeholder USE insns
previously inserted by update_block.
Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3991,6 +3991,9 @@ dbr_schedule (rtx first)
if (GET_CODE (pat) == SEQUENCE)
insn = XVECEXP (pat, 0, 0);
}
+ if (INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
+INSN_P (XEXP (PATTERN (insn), 0)))
+ delete_insn (insn);
if (!JUMP_P (insn))
continue;
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes:
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
I see code in dbr_schedule to delete them:
/* Delete any USE insns made by update_block; subsequent passes don't need
them or know how to deal with them. */
for (insn = first; insn; insn = next)
{
next = NEXT_INSN (insn);
if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}
Why is that not working?
Ian
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes:
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
I see code in dbr_schedule to delete them:
/* Delete any USE insns made by update_block; subsequent passes don't need
them or know how to deal with them. */
for (insn = first; insn; insn = next)
{
next = NEXT_INSN (insn);
if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}
Why is that not working?
Hmm, good catch. I didn't noticed that code.
The problem is that update_block is still called after this loop is
done, at least moving that loop down past the loop just bellow it solves
the ICE too.
I must admit I have no idea what those placeholders are good for...
Honza
Ian
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes:
Jan Hubicka [EMAIL PROTECTED] writes:
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
I see code in dbr_schedule to delete them:
/* Delete any USE insns made by update_block; subsequent passes don't need
them or know how to deal with them. */
for (insn = first; insn; insn = next)
{
next = NEXT_INSN (insn);
if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}
Why is that not working?
Hmm, good catch. I didn't noticed that code.
The problem is that update_block is still called after this loop is
done, at least moving that loop down past the loop just bellow it solves
the ICE too.
Ah, it's from the calls to fill_simple_delay_slots in
make_return_insns. The Delete any USE insns loop needs to move
below that.
I must admit I have no idea what those placeholders are good for...
They tell mark_target_live_regs that the registers used by the insn
which was moved are live.
Ian
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes:
Jan Hubicka [EMAIL PROTECTED] writes:
Producing USE expressions embedding whole INSN. The comment promise
that those will be removed before reorg ends, but they are not. This
patch just adds simple code to remove them in very last dbr_schedule
pass.
I see code in dbr_schedule to delete them:
/* Delete any USE insns made by update_block; subsequent passes don't
need
them or know how to deal with them. */
for (insn = first; insn; insn = next)
{
next = NEXT_INSN (insn);
if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
INSN_P (XEXP (PATTERN (insn), 0)))
next = delete_related_insns (insn);
}
Why is that not working?
Hmm, good catch. I didn't noticed that code.
The problem is that update_block is still called after this loop is
done, at least moving that loop down past the loop just bellow it solves
the ICE too.
Ah, it's from the calls to fill_simple_delay_slots in
make_return_insns. The Delete any USE insns loop needs to move
below that.
I must admit I have no idea what those placeholders are good for...
They tell mark_target_live_regs that the registers used by the insn
which was moved are live.
Ah, I see.
The attached patch seems to work on my testcase too.
Honza
Index: reorg.c
===
--- reorg.c (revision 128145)
+++ reorg.c (working copy)
@@ -3863,17 +3863,6 @@ dbr_schedule (rtx first)
relax_delay_slots (first);
}
- /* Delete any USE insns made by update_block; subsequent passes don't need
- them or know how to deal with them. */
- for (insn = first; insn; insn = next)
-{
- next = NEXT_INSN (insn);
-
- if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
- INSN_P (XEXP (PATTERN (insn), 0)))
- next = delete_related_insns (insn);
-}
-
/* If we made an end of function label, indicate that it is now
safe to delete it by undoing our prior adjustment to LABEL_NUSES.
If it is now unused, delete it. */
@@ -3885,6 +3874,17 @@ dbr_schedule (rtx first)
make_return_insns (first);
#endif
+ /* Delete any USE insns made by update_block; subsequent passes don't need
+ them or know how to deal with them. */
+ for (insn = first; insn; insn = next)
+{
+ next = NEXT_INSN (insn);
+
+ if (NONJUMP_INSN_P (insn) GET_CODE (PATTERN (insn)) == USE
+ INSN_P (XEXP (PATTERN (insn), 0)))
+ next = delete_related_insns (insn);
+}
+
obstack_free (unfilled_slots_obstack, unfilled_firstobj);
/* It is not clear why the line below is needed, but it does seem to be. */
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
Jan Hubicka [EMAIL PROTECTED] writes: The attached patch seems to work on my testcase too. This patch is OK if it passes testing and gets a ChangeLog entry. Thanks. Ian
Re: RTL sharing bootstrap failure on sparc-sun-solaris2.10
On Thu, 6 Sep 2007, Jan Hubicka wrote: Hi, I already have fix for this just waiting for Andreas Tobler to verify that it does what expected. If you could give it a try, it would be nice. Honza Index: reorg.c === --- reorg.c (revision 128145) +++ reorg.c (working copy) @@ -3991,6 +3991,9 @@ dbr_schedule (rtx first) if (GET_CODE (pat) == SEQUENCE) insn = XVECEXP (pat, 0, 0); } + if (INSN_P (insn) GET_CODE (PATTERN (insn)) == USE +INSN_P (XEXP (PATTERN (insn), 0))) + delete_insn (insn); if (!JUMP_P (insn)) continue; FWIW, this patch fixes the problem. Test results here: http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00313.html I'll try again with your updated version tonight. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
[Bug bootstrap/32312] [4.3 regression] bootstrap failure on sparc-sun-solaris2.10
--- Comment #3 from ghazi at gcc dot gnu dot org 2007-06-13 15:45 --- Fixed: http://gcc.gnu.org/ml/gcc-testresults/2007-06/msg00615.html by this patch: http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00842.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32312
[Bug bootstrap/32312] New: [4.3.0 regression] bootstrap failure on sparc-sun-solaris2.10
I'm getting a new bootstrap failure on sparc-sun-solaris2.10 in stage1 building libgcc2.a: /tmp/kg/pat/build/./gcc/xgcc -B/tmp/kg/pat/build/./gcc/ -B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/ -isystem /usr/local/sparc-sun-solaris2.10/include -isystem /usr/local/sparc-sun-solaris2.10/sys-include -O2 -g -O2 -O2 -g -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../.././gcc -I../../../egcc-SVN20070612/libgcc -I../../../egcc-SVN20070612/libgcc/. -I../../../egcc-SVN20070612/libgcc/../gcc -I../../../egcc-SVN20070612/libgcc/../include -o _absvdi2.o -MT _absvdi2.o -MD -MP -MF _absvdi2.dep -DL_absvdi2 -c ../../../egcc-SVN20070612/libgcc/../gcc/libgcc2.c \ ../../../egcc-SVN20070612/libgcc/../gcc/libgcc2.c: In function '__absvdi2': ../../../egcc-SVN20070612/libgcc/../gcc/libgcc2.c:280: internal compiler error: Segmentation Fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_absvdi2.o] Error 1 -- Summary: [4.3.0 regression] bootstrap failure on sparc-sun- solaris2.10 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32312
[Bug bootstrap/32312] [4.3.0 regression] bootstrap failure on sparc-sun-solaris2.10
--- Comment #1 from ghazi at gcc dot gnu dot org 2007-06-12 20:37 ---
This worked as of June 9th, so it's recent.
The SEGV happens because df (used in the macro DF_REG_DEF_COUNT) is nil:
signal SEGV (no mapping at the fault address) in sparc_check_64 at line 7677 in
file sparc.c
7677 DF_REG_DEF_COUNT (REGNO (y)) == 1)
(dbx) where
=[1] sparc_check_64(x = 0xff168620, insn = 0xff123810), line 7677 in sparc.c
[2] output_v8plus_shift(operands = 0x1f07484, insn = 0xff123810, opcode =
0x1e8e364 srax), line 7741 in sparc.c
[3] output_363(operands = 0x1f07484, insn = 0xff123810), line 6499 in
sparc.md
[4] get_insn_template(code = 363, insn = 0xff123810), line 1584 in final.c
[5] final_scan_insn(insn = 0xff123810, file = 0x1f013c8, optimize = 2,
nopeepholes = 0, seen = 0xffbff22c), line 2460 in final.c
[6] final(first = 0xff123658, file = 0x1f013c8, optimize = 2), line 1569 in
final.c
[7] rest_of_handle_final(), line 3973 in final.c
[8] execute_one_pass(pass = 0x1ec37ec), line 1124 in passes.c
[9] execute_pass_list(pass = 0x1ec37ec), line 1177 in passes.c
[10] execute_pass_list(pass = 0x1ec3d94), line 1178 in passes.c
[11] execute_pass_list(pass = 0x1ec3d60), line 1178 in passes.c
[12] tree_rest_of_compilation(fndecl = 0xff154d20), line 406 in
tree-optimize.c
[13] c_expand_body(fndecl = 0xff154d20), line 4331 in c-common.c
[14] cgraph_expand_function(node = 0xff15fb30), line 1073 in cgraphunit.c
[15] cgraph_expand_all_functions(), line 1142 in cgraphunit.c
[16] cgraph_optimize(), line 1349 in cgraphunit.c
[17] c_write_global_declarations(), line 7911 in c-decl.c
[18] compile_file(), line 1064 in toplev.c
[19] do_compile(), line 2150 in toplev.c
[20] toplev_main(argc = 25U, argv = 0xffbff92c), line 2182 in toplev.c
[21] main(argc = 25, argv = 0xffbff92c), line 35 in main.c
(dbx) list
7677 DF_REG_DEF_COUNT (REGNO (y)) == 1)
7678 set_once = 1;
7679
7680 if (insn == 0)
7681 {
7682 if (set_once)
7683 insn = get_last_insn_anywhere ();
7684 else
7685 return 0;
7686 }
(dbx) print df
df = (nil)
(dbx)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32312
[Bug bootstrap/32312] [4.3.0 regression] bootstrap failure on sparc-sun-solaris2.10
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32312
[Bug bootstrap/32312] [4.3.0 regression] bootstrap failure on sparc-sun-solaris2.10
--- Comment #2 from ghazi at gcc dot gnu dot org 2007-06-12 20:59 --- Created an attachment (id=13693) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13693action=view) testcase for ICE Target sparc-sun-solaris2.10 and run: cc1 -fpreprocessed libgcc2.i -quiet -dumpbase libgcc2.c -mcpu=v9 -auxbase-strip _absvdi2.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version -fPIC -o libgcc2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32312
Re: Bootstrap failure on sparc*-sun-solaris2.10
On Tue, Jan 24, 2006 at 11:55:32PM -0500, Kaveh R. Ghazi wrote:
Okay, now I get:
[...]
build/gencondmd.c, line 60: incomplete struct/union/enum c_test:
insn_conditions
build/gencondmd.c, line 1952: warning: syntax error: empty initializer
build/gencondmd.c, line 1952: cannot recover from previous errors
cc: acomp failed for build/gencondmd.c
make[3]: *** [build/gencondmd.o] Error 2
On Wed, Jan 25, 2006 at 02:04:04PM +0100, Andreas Krebbel wrote:
the insn-conditions.md file doesn't preserve escaping of
characters. So in the s390.md example
CONST_OK_FOR_CONSTRAINT_P (INTVAL (operands[2]), 'K', \K\)
becomes
CONST_OK_FOR_CONSTRAINT_P (INTVAL (operands[2]), 'K', K)
which a syntax error for the gen... tools.
The appended patch (superseding the earlier one, Kaveh) should fix
both these issues. I have to run off to school and won't be able
to do anything more till this evening, but please let me know how
it goes.
zw
==
--- genconditions.c (revision 110242)
+++ genconditions.c (local)
@@ -52,9 +52,14 @@ write_header (void)
machine description file. */\n\
\n\
#include \bconfig.h\\n\
-#include \insn-constants.h\\n);
+#include \system.h\\n);
puts (\
+/* It is necessary, but not entirely safe, to include the headers below\n\
+ in a generator program. As a defensive measure, don't do so when the\n\
+ table isn't going to have anything in it. */\n\
+#if GCC_VERSION = 3001\n\
+\n\
/* Do not allow checking to confuse the issue. */\n\
#undef ENABLE_CHECKING\n\
#undef ENABLE_TREE_CHECKING\n\
@@ -64,9 +69,9 @@ write_header (void)
#undef ENABLE_GC_ALWAYS_COLLECT\n);
puts (\
-#include \system.h\\n\
#include \coretypes.h\\n\
#include \tm.h\\n\
+#include \insn-constants.h\\n\
#include \rtl.h\\n\
#include \tm_p.h\\n\
#include \function.h\\n);
@@ -86,8 +91,7 @@ write_header (void)
#include \hard-reg-set.h\\n\
#include \resource.h\\n\
#include \toplev.h\\n\
-#include \reload.h\\n\
-#include \gensupport.h\\n);
+#include \reload.h\\n);
if (saw_eh_return)
puts (#define HAVE_eh_return 1);
@@ -97,7 +101,9 @@ write_header (void)
/* Dummy external declarations. */\n\
extern rtx insn;\n\
extern rtx ins1;\n\
-extern rtx operands[];\n);
+extern rtx operands[];\n\
+\n\
+#endif /* gcc = 3.0.1 */\n);
}
/* Write out one entry in the conditions table, using the data pointed
@@ -118,12 +124,14 @@ write_one_condition (void **slot, void *
fputs ( { \, stdout);
for (p = test-expr; *p; p++)
{
- if (*p == '\n')
- fputs (\\n\\\n, stdout);
- else if (*p == '')
- fputs (\\\, stdout);
- else
- putchar (*p);
+ switch (*p)
+ {
+ case '\n': fputs (\\n\\, stdout); break;
+ case '\\':
+ case '\': putchar ('\\'); break;
+ default: break;
+ }
+ putchar (*p);
}
printf (\,\n__builtin_constant_p );
@@ -140,20 +148,29 @@ static void
write_conditions (void)
{
puts (\
+/* Structure definition duplicated from gensupport.h rather than\n\
+ drag in that file and its dependencies. */\n\
+struct c_test\n\
+{\n\
+ const char *expr;\n\
+ int value;\n\
+};\n);
+
+ puts (\
/* This table lists each condition found in the machine description.\n\
Each condition is mapped to its truth value (0 or 1), or -1 if that\n\
- cannot be calculated at compile time. */\n\
-\n\
-static const struct c_test insn_conditions[] = {\n \
-/* If we don't have __builtin_constant_p, or it's not acceptable in array\n\
+ cannot be calculated at compile time.\n\
+ If we don't have __builtin_constant_p, or it's not acceptable in array\n\
initializers, fall back to assuming that all conditions potentially\n\
vary at run time. It works in 3.0.1 and later; 3.0 only when not\n\
optimizing. */\n\
-#if GCC_VERSION = 3001);
+\n\
+static const struct c_test insn_conditions[] = {\n\
+#if GCC_VERSION = 3001\n);
traverse_c_tests (write_one_condition, 0);
- puts (#endif\n};\n);
+ puts (\n#endif /* gcc = 3.0.1 */\n};\n);
}
/* Emit code which will convert the C-format table to a
@@ -163,16 +180,31 @@ static const struct c_test insn_conditio
static void
write_writer (void)
{
- puts (int\nmain(void)\n{\n\
- unsigned int i;\n\
-\n\
- puts (\(define_conditions [\);\n\
- for (i = 0; i ARRAY_SIZE (insn_conditions); i++)\n\
-printf (\ (%d \\\%s\\\)\\n\,\n\
- insn_conditions[i].value, insn_conditions[i].expr);\n\
- puts (\])\);\n\
- fflush (stdout);\n\
- return (ferror (stdout) != 0 ? FATAL_EXIT_CODE : SUCCESS_EXIT_CODE);\n});
+ puts (int\n
+ main(void)\n
+ {\n
+ unsigned int i;\n
+ const char *p;\n
+ puts (\(define_conditions [\);\n
+ for (i = 0; i ARRAY_SIZE (insn_conditions); i++)\n
+ {\n
+ printf (\ (%d , insn_conditions[i].value);\n
+ for (p = insn_conditions[i].expr; *p; p++)\n
+
Re: Bootstrap failure on sparc*-sun-solaris2.10
The appended patch (superseding the earlier one, Kaveh) should fix both these issues. I have to run off to school and won't be able to do anything more till this evening, but please let me know how it goes. zw Zack - using your latest genconditions.c patch plus this one: http://gcc.gnu.org/ml/gcc/2006-01/msg00951.html was sufficient to get a C-only bootstrap working on solaris2.10 using cc for stage1. I'm going to run a full test, but that'll take many many hours longer. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Bootstrap failure on sparc*-sun-solaris2.10
Zack - using your latest genconditions.c patch plus this one: http://gcc.gnu.org/ml/gcc/2006-01/msg00951.html was sufficient to get a C-only bootstrap working on solaris2.10 using cc for stage1. I'm going to run a full test, but that'll take many many hours longer. Ok, I've now completed a full bootstrap and testsuite run with the two patches on sparc-solaris2.10. There are many java failures so we're not out of the woods. But at least we're back to bootstrapping. http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01332.html Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Bootstrap failure on sparc*-sun-solaris2.10
I'm getting the following new bootstrap failure on both sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for stage1: cc -xildoff -xarch=v9 -c -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../egcc-SVN20060124/gcc -I../../egcc-SVN20060124/gcc/build --I../../egcc-SVN20060124/gcc/../include -I./../intl --I../../egcc-SVN20060124/gcc/../libcpp/include --I/caip/u12/kishgcc/gcc-testing/_gmp64/include --I../../egcc-SVN20060124/gcc/../libdecnumber -I../libdecnumber -o -build/gencondmd.o build/gencondmd.c build/gencondmd.c, line 1943: warning: syntax error: empty initializer build/gencondmd.c, line 1943: warning: null dimension: insn_conditions build/gencondmd.c, line 1951: warning: null dimension: sizeof() cc -xildoff -xarch=v9 -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -o build/gencondmd \ build/gencondmd.o ../build-sparc64-sun-solaris2.10/libiberty/libiberty.a Undefined first referenced symbol in file vec_heap_p_reserve build/gencondmd.o bitmap_zero_bitsbuild/gencondmd.o vec_gc_p_reservebuild/gencondmd.o vec_gc_o_reservebuild/gencondmd.o ggc_freebuild/gencondmd.o fancy_abort build/gencondmd.o ld: fatal: Symbol referencing errors. No output written to build/gencondmd At least some of this (e.g. bitmap_zero_bits) is due to uses in static inline functions where inline gets defined to nothing for !GCC and therefore the function is not eliminated. I made some progress by linking with: build/vec.o build/ggc-none.o $(BUILD_ERRORS) however I still had a reference to bitmap_zero_bits and I don't see that a build copy of bitmap.o is ever built. I don't like this solution anyway because it isn't supposedly necessary to link in the extra objects during stage2 where we have GCC and inline gets turned on again. I'm also not feeling comfy given the warnings about null dimensions above. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Bootstrap failure on sparc*-sun-solaris2.10
Not this issue again :(. I thought I fixed it the last time it came up. -- Pinski URL? -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Bootstrap failure on sparc*-sun-solaris2.10
On Jan 24, 2006, at 10:41 PM, Kaveh R. Ghazi wrote: Not this issue again :(. I thought I fixed it the last time it came up. -- Pinski URL? Maybe I did not fix it but it was a problem in the past. This was PR 18058 for 4.0.0. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058 -- Pinski
Re: Bootstrap failure on sparc*-sun-solaris2.10
On Tue, Jan 24, 2006 at 10:29:08PM -0500, Kaveh R. Ghazi wrote:
I'm getting the following new bootstrap failure on both
sparc-sun-solaris2.10 and sparc64-sun-solaris2.10 when using cc for
stage1:
build/gencondmd.c, line 1943: warning: syntax error: empty initializer
build/gencondmd.c, line 1943: warning: null dimension: insn_conditions
build/gencondmd.c, line 1951: warning: null dimension: sizeof()
cc -xildoff -xarch=v9 -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -o
build/gencondmd \ build/gencondmd.o
../build-sparc64-sun-solaris2.10/libiberty/libiberty.a
Undefined first referenced
symbol in file
vec_heap_p_reserve build/gencondmd.o
bitmap_zero_bitsbuild/gencondmd.o
vec_gc_p_reservebuild/gencondmd.o
vec_gc_o_reservebuild/gencondmd.o
ggc_freebuild/gencondmd.o
fancy_abort build/gencondmd.o
I'm not entirely understanding why this breaks now when insn-conditions.o
was fine, but a potential big-hammer fix is to put
#if GCC_VERSION = 3001 ... #endif around most of the includes, like in the
appended patch. Would you please try it?
zw
* genconditions.c (write_header): In generated code, #if
out all headers and fake declarations, except bconfig.h
and system.h, when not compiling with GCC = 3.0.1.
(write_conditions): Tweak commentary in generated code.
==
--- genconditions.c (revision 110239)
+++ genconditions.c (local)
@@ -52,9 +52,14 @@ write_header (void)
machine description file. */\n\
\n\
#include \bconfig.h\\n\
-#include \insn-constants.h\\n);
+#include \system.h\\n);
puts (\
+/* It is necessary, but not entirely safe, to include the headers below\n\
+ in a generator program. As a defensive measure, don't do so when the\n\
+ table isn't going to have anything in it. */\n\
+#if GCC_VERSION = 3001\n\
+\n\
/* Do not allow checking to confuse the issue. */\n\
#undef ENABLE_CHECKING\n\
#undef ENABLE_TREE_CHECKING\n\
@@ -64,9 +69,9 @@ write_header (void)
#undef ENABLE_GC_ALWAYS_COLLECT\n);
puts (\
-#include \system.h\\n\
#include \coretypes.h\\n\
#include \tm.h\\n\
+#include \insn-constants.h\\n\
#include \rtl.h\\n\
#include \tm_p.h\\n\
#include \function.h\\n);
@@ -97,7 +102,9 @@ write_header (void)
/* Dummy external declarations. */\n\
extern rtx insn;\n\
extern rtx ins1;\n\
-extern rtx operands[];\n);
+extern rtx operands[];\n\
+\n\
+#endif /* gcc = 3.0.1 */\n);
}
/* Write out one entry in the conditions table, using the data pointed
@@ -142,18 +149,18 @@ write_conditions (void)
puts (\
/* This table lists each condition found in the machine description.\n\
Each condition is mapped to its truth value (0 or 1), or -1 if that\n\
- cannot be calculated at compile time. */\n\
-\n\
-static const struct c_test insn_conditions[] = {\n \
-/* If we don't have __builtin_constant_p, or it's not acceptable in array\n\
+ cannot be calculated at compile time.\n\
+ If we don't have __builtin_constant_p, or it's not acceptable in array\n\
initializers, fall back to assuming that all conditions potentially\n\
vary at run time. It works in 3.0.1 and later; 3.0 only when not\n\
optimizing. */\n\
-#if GCC_VERSION = 3001);
+\n\
+static const struct c_test insn_conditions[] = {\n\
+#if GCC_VERSION = 3001\n);
traverse_c_tests (write_one_condition, 0);
- puts (#endif\n};\n);
+ puts (\n#endif /* gcc = 3.0.1 */\n};\n);
}
/* Emit code which will convert the C-format table to a
Re: Bootstrap failure on sparc*-sun-solaris2.10
I'm not entirely understanding why this breaks now when insn-conditions.o was fine, but a potential big-hammer fix is to put #if GCC_VERSION = 3001 ... #endif around most of the includes, like in the appended patch. Would you please try it? zw * genconditions.c (write_header): In generated code, #if out all headers and fake declarations, except bconfig.h and system.h, when not compiling with GCC = 3.0.1. (write_conditions): Tweak commentary in generated code. Okay, now I get: cc -c -g -DIN_GCC -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../egcc-SVN20060124/gcc -I../../egcc-SVN20060124/gcc/build -I../../egcc-SVN20060124/gcc/../include -I../../egcc-SVN20060124/gcc/../libcpp/include -I../../egcc-SVN20060124/gcc/../libdecnumber -I../libdecnumber -o build/gencondmd.o build/gencondmd.c build/gencondmd.c, line 60: incomplete struct/union/enum c_test: insn_conditions build/gencondmd.c, line 1952: warning: syntax error: empty initializer build/gencondmd.c, line 1952: cannot recover from previous errors cc: acomp failed for build/gencondmd.c make[3]: *** [build/gencondmd.o] Error 2 (I'm going to sleep, so I won't be able to test anything more until tomorrow.) -- Kaveh R. Ghazi [EMAIL PROTECTED]
