[Bug middle-end/26991] Target Help Seg Fault.
--- Comment #2 from corsepiu at gcc dot gnu dot org 2006-06-26 14:34 --- # m68k-rtems4.7-gcc --target-help Target specific options: cc1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. # m68k-rtems4.7-gcc --target-help -v Using built-in specs. Target: m68k-rtems4.7 Configured with: ../gcc-4.1.1/configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=m68k-rtems4.7 --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --enable-languages=c,c++ Thread model: single gcc version 4.1.1 /usr/libexec/gcc/m68k-rtems4.7/4.1.1/cc1 -quiet -v help-dummy -quiet -dumpbase help-dummy -auxbase help-dummy -version --target-help -o /tmp/cclQfte8.s Target specific options: cc1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- corsepiu at gcc dot gnu dot org changed: What|Removed |Added CC| |corsepiu at gcc dot gnu dot | |org Known to fail||4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug middle-end/26991] Target Help Seg Fault.
--- Comment #3 from corsepiu at gcc dot gnu dot org 2006-06-26 16:41
---
Traceback:
Program received signal SIGSEGV, Segmentation fault.
print_filtered_help (flag=4194304) at ../../gcc-4.1.1/gcc/opts.c:1301
(gdb) where
#0 print_filtered_help (flag=4194304) at ../../gcc-4.1.1/gcc/opts.c:1301
#1 0x081f61d7 in decode_options (argc=13, argv=0xbfc6fc34) at
../../gcc-4.1.1/gcc/opts.c:738
#2 0x08243b08 in toplev_main (argc=13, argv=0xbfc6fc34) at
../../gcc-4.1.1/gcc/toplev.c:1975
#3 0x080978f2 in main (argc=0, argv=0x1f9) at ../../gcc-4.1.1/gcc/main.c:35
#4 0x00b68724 in __libc_start_main () from /lib/libc.so.6
#5 0x08049ad1 in _start ()
The offending code is this (From gcc-4.1.1/gcc/opts.c):
1293 const char *help, *opt, *tab;
1294 static char *printed;
1295
1296 if (flag == CL_COMMON || flag == CL_TARGET)
1297 {
1298 filter = flag;
1299 if (!printed)
1300 printed = xmalloc (cl_options_count);
1301 memset (printed, 0, cl_options_count);
1302 }
=> the SEGFAULT occurs in memset.
Could it be, "static char* printed" should be initialized = 0?
I.e. static char* printed = 0;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug middle-end/26991] [4.1 Regression] Target Help Seg Fault.
--- Comment #6 from corsepiu at gcc dot gnu dot org 2006-06-26 17:01 --- (In reply to comment #5) > PR 25636 was the 4.2.0 bug and the patch there should fix it if someone > backports it. For the record, the compiler exposing this is FC5's gcc-4.1.1-1.fc5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26991
[Bug target/21578] ICE in reload_cse_simplify_operands for Coldfire.
--- Comment #5 from corsepiu at gcc dot gnu dot org 2005-11-20 05:38 --- (In reply to comment #4) > Is this still reproducible? > A quick check with m68k-none-elf did not reproduce the ICE. Confirmed, I can't reproduce it with my latest rtems-toolchain: m68k-rtems4.7-gcc (GCC) 4.0.1 (RTEMS gcc-4.0.1-20050727/newlib-1.13.0-20050912 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
[Bug target/19421] [4.0/4.1/4.2 regression] ICE with soft-float on m68k
--- Comment #17 from corsepiu at gcc dot gnu dot org 2005-11-23 10:30 --- Vanilla 4.0.2 with no further patches applied still fails for me: # m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O2 -msoft-float pr19421-1.c: In function 'paranoia': pr19421-1.c:2084: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- corsepiu at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 4.0.1 |4.0.0 4.0.1 4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/25780] New: ICE
sparc-rtems4.7-gcc -O2 smc9.i smc9.c: In function 'smc9_rxDaemon':
smc9.c:481: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
# sparc-rtems4.7-gcc --version
sparc-rtems4.7-gcc (GCC) 4.0.2 (RTEMS
gcc-4.0.2-20051124/newlib-1.14.0-20051219-0.20051229.0.fc4)
i.e. GCC-4.0-branch as of 2005-11-24 with newlib-1.14.0
--
Summary: ICE
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: sparc-*-elf*/sparc-*-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25780
[Bug target/25780] ICE
--- Comment #1 from corsepiu at gcc dot gnu dot org 2006-01-13 03:57 --- Created an attachment (id=10636) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10636&action=view) --save-temps generated file from the ICE GCC ices on this code with -O2, but doesn't ice with -O1 or -O0: # sparc-rtems4.7-gcc -O1 -c smc9.i # sparc-rtems4.7-gcc -O2 -c smc9.i smc9.c: In function 'smc9_rxDaemon': smc9.c:481: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25780
[Bug target/32307] ICE building simple httpd log.c for -m5282x option
--- Comment #4 from corsepiu at gcc dot gnu dot org 2007-07-30 08:11 --- Having investigated this breakdown further, I can reproduce it for many coldfire variants. Also: FWIW: Adding -fomit-frame-pointer lets the ICE disappear. -- corsepiu at gcc dot gnu dot org changed: What|Removed |Added Known to fail|3.2.3 4.1.1 4.2.0 |3.2.3 4.1.1 4.2.0 4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32307
[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-16 07:35 --- (In reply to comment #12) > A call for testing patch is here: <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00858.html>. With this patch applied, GCC-4.0 (20050216) builds again for avr-rtems* and h8300-rtems*. While building, I noticed warnings from math code in newlib, I haven't noticed before. I am not sure whether these warnings had been present before or not and if these are related to this patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
[Bug target/20007] New: error: too many arguments to function `find_basic_blocks
# gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fno-common
-DHAVE_CONFIG_H-I. -I. -I../../gcc-4.0.0/gcc -I../../gcc-4.0.0/gcc/.
-I../../gcc-4.0.0/gcc/../include -I../../gcc-4.0.0/gcc/../libcpp/include \
../../gcc-4.0.0/gcc/config/sh/sh.c -o sh.o
../../gcc-4.0.0/gcc/config/sh/sh.c: In function `sh_output_mi_thunk':
../../gcc-4.0.0/gcc/config/sh/sh.c:9858: error: too many arguments to function
`find_basic_blocks'
make[1]: *** [sh.o] Error 1
make[1]: Leaving directory
`/users/rtems/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc'
make: *** [all-gcc] Error 2
Presumable trigger of this breakdown is this patch:
2005-02-14 Kazu Hirata <[EMAIL PROTECTED]>
* basic-block.h: Adjust the prototype for find_basic_blocks.
--
Summary: error: too many arguments to function `find_basic_blocks
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,kazu at cs dot umass dot
edu
GCC target triplet: sh-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20007
[Bug middle-end/19920] [4.0 Regression] build broken on several targets due to recent 'DC' type update to libgcc2
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-16 15:15 --- (In reply to comment #15) > > From: corsepiu at gcc dot gnu dot org <[EMAIL PROTECTED]> > > While building, I noticed warnings from math code in newlib, I haven't > > noticed before. I am not sure whether these warnings had been present > > before or not and if these are related to this patch. > > Like ...? Here's one (target: h8300-rtems4.7): ../../../../../../gcc-4.0.0/newlib/libm/math/ef_remainder.c:49: warning: left shift count >= width of type There are dozens of similar warnings in my build-log. Having a look into newlib shows all of these warnings to be related to sizeof(int) vs. sizeof(long) vs. sizeof(void*), not to float/double. I know newlib, is partially broken, in assuming sizeof(int)==sizeof(long)==sizeof(void*)==32bit, but ... ... I have several local patches to newlib applied, which are supposed to fix them. So, unless something has changed these sizes, I probably didn't work carefully enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-07 08:26 --- I can reproduce it with gcc-4.0.0 (20050406) Interestingly, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421#c7 does not ICE with -mO0, -mO2, -mO3! -- What|Removed |Added Known to fail|3.4.3 3.4.4 |3.4.3 3.4.4 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18421
[Bug middle-end/36583] [4.3/4.4 Regression] ICE on 5282/5206 at -O2
--- Comment #5 from corsepiu at gcc dot gnu dot org 2008-08-30 05:13 --- With gcc-4.3.2, for me, the "j1.c" testcase doesn't segfault anymore. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36583
[Bug target/35071] New: bad instruction `do_itt eq'
Building today's gcc-trunk (rev. 132088/2008-02-04) for arm-rtems4.9 fails with: ... /users/rtems/src/toolchains/BUILD/arm-rtems4.9/./gcc/xgcc -B/users/rtems/src/toolchains/BUILD/arm-rtems4.9/./gcc/ -nostdinc -B/users/rtems/src/toolchains/BUILD/arm-rtems4.9/arm-rtems4.9/newlib/ -isystem /users/rtems/src/toolchains/BUILD/arm-rtems4.9/arm-rtems4.9/newlib/targ-include -isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include -B/opt/rtems-4.9/arm-rtems4.9/bin/ -B/opt/rtems-4.9/arm-rtems4.9/lib/ -isystem /opt/rtems-4.9/arm-rtems4.9/include -isystem /opt/rtems-4.9/arm-rtems4.9/sys-include -O2 -g -g -O2 -mhard-float -O2 -I../../../gcc-trunk/gcc/../newlib/libc/sys/rtems/include -O2 -g -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-inline -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../../gcc-trunk/libgcc -I../../../../../gcc-trunk/libgcc/. -I../../../../../gcc-trunk/libgcc/../gcc -I../../../../../gcc-trunk/libgcc/../include -DHAVE_CC_TLS -o _addsubdf3.o -MT _addsubdf3.o -MD -MP -MF _addsubdf3.dep -DL_addsubdf3 -xassembler-with-cpp \ -c ../../../../../gcc-trunk/libgcc/../gcc/config/arm/lib1funcs.asm ../../../../../gcc-trunk/libgcc/../gcc/config/arm/ieee754-df.S: Assembler messages: ../../../../../gcc-trunk/libgcc/../gcc/config/arm/ieee754-df.S:529: Error: bad instruction `do_itt eq' make[4]: *** [_addsubdf3.o] Error 1 make[4]: Leaving directory `/users/rtems/src/toolchains/BUILD/arm-rtems4.9/arm-rtems4.9/fpu/libgcc' -- Summary: bad instruction `do_itt eq' Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org GCC target triplet: arm-rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
[Bug target/35072] New: h8300: ICE unwind-dw2-fde.c:650: error: unrecognizable insn
Building today's gcc-trunk (rev. 132088/2008-02-04) for target h8300-rtems4.9
fails with an ICE:
...
/users/rtems/src/toolchains/BUILD/h8300-rtems4.9/./gcc/xgcc
-B/users/rtems/src/toolchains/BUILD/h8300-rtems4.9/./gcc/ -nostdinc
-B/users/rtems/src/toolchains/BUILD/h8300-rtems4.9/h8300-rtems4.9/newlib/
-isystem
/users/rtems/src/toolchains/BUILD/h8300-rtems4.9/h8300-rtems4.9/newlib/targ-include
-isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include
-B/opt/rtems-4.9/h8300-rtems4.9/bin/ -B/opt/rtems-4.9/h8300-rtems4.9/lib/
-isystem /opt/rtems-4.9/h8300-rtems4.9/include -isystem
/opt/rtems-4.9/h8300-rtems4.9/sys-include -O2 -g -g -O2 -O2
-I../../../gcc-trunk/gcc/../newlib/libc/sys/rtems/include -O2 -g -g -O2
-DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -DDF=SF -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I. -I../.././gcc -I../../../../gcc-trunk/libgcc
-I../../../../gcc-trunk/libgcc/. -I../../../../gcc-trunk/libgcc/../gcc
-I../../../../gcc-trunk/libgcc/../include -DHAVE_CC_TLS -o unwind-dw2-fde.o
-MT unwind-dw2-fde.o -MD -MP -MF unwind-dw2-fde.dep -fexceptions -c
../../../../gcc-trunk/libgcc/../gcc/unwind-dw2-fde.c
../../../../gcc-trunk/libgcc/../gcc/unwind-dw2-fde.c: In function
'classify_object_over_fdes':
../../../../gcc-trunk/libgcc/../gcc/unwind-dw2-fde.c:650: error: unrecognizable
insn:
(insn 84 83 85 12 ../../../../gcc-trunk/libgcc/../gcc/unwind-dw2-fde.c:625 (set
(zero_extract:HI (subreg:HI (reg:QI 55) 0)
(const_int 1 [0x1])
(const_int 5 [0x5]))
(const_int 1 [0x1])) -1 (nil))
../../../../gcc-trunk/libgcc/../gcc/unwind-dw2-fde.c:650: internal compiler
error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: *** [unwind-dw2-fde.o] Error 1
make[2]: Leaving directory
`/users/rtems/src/toolchains/BUILD/h8300-rtems4.9/h8300-rtems4.9/libgcc'
make[1]: *** [all-target-libgcc] Error 2
--
Summary: h8300: ICE unwind-dw2-fde.c:650: error: unrecognizable
insn
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: h8300-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35072
[Bug target/35073] New: illegal opcode movw for mcu avr3
Building/bootstrapping today's gcc-trunk (rev. 132088/2008-02-04) for avr-rtems4.9 fails with: ... /users/rtems/src/toolchains/BUILD/avr-rtems4.9/./gcc/xgcc -B/users/rtems/src/toolchains/BUILD/avr-rtems4.9/./gcc/ -nostdinc -B/users/rtems/src/toolchains/BUILD/avr-rtems4.9/avr-rtems4.9/newlib/ -isystem /users/rtems/src/toolchains/BUILD/avr-rtems4.9/avr-rtems4.9/newlib/targ-include -isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include -B/opt/rtems-4.9/avr-rtems4.9/bin/ -B/opt/rtems-4.9/avr-rtems4.9/lib/ -isystem /opt/rtems-4.9/avr-rtems4.9/include -isystem /opt/rtems-4.9/avr-rtems4.9/sys-include -O2 -g -g -O2 -mmcu=avr35 -O2 -I../../../gcc-trunk/gcc/../newlib/libc/sys/rtems/include -O2 -g -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -Os -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../../gcc-trunk/libgcc -I../../../../../gcc-trunk/libgcc/. -I../../../../../gcc-trunk/libgcc/../gcc -I../../../../../gcc-trunk/libgcc/../include -o _mulsi3.o -MT _mulsi3.o -MD -MP -MF _mulsi3.dep -DL_mulsi3 -xassembler-with-cpp \ -c ../../../../../gcc-trunk/libgcc/../gcc/config/avr/libgcc.S ../../../../../gcc-trunk/libgcc/../gcc/config/avr/libgcc.S: Assembler messages: ../../../../../gcc-trunk/libgcc/../gcc/config/avr/libgcc.S:281: Error: illegal opcode movw for mcu avr3 ../../../../../gcc-trunk/libgcc/../gcc/config/avr/libgcc.S:283: Error: illegal opcode movw for mcu avr3 make[4]: *** [_mulsi3.o] Error 1 make[4]: Leaving directory `/users/rtems/src/toolchains/BUILD/avr-rtems4.9/avr-rtems4.9/avr35/libgcc' -- Summary: illegal opcode movw for mcu avr3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org GCC target triplet: avr-rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35073
[Bug target/35083] New: ICE: in extract_insn, at recog.c:1990
Building gcc-trunk rev 132111 (2008-02-05) for i386-rtems* (elf w/ newlib)
fails with:
...
make[7]: Entering directory
`/users/rtems/src/toolchains/BUILD/i386-rtems4.9/i386-rtems4.9/soft-float/newlib/libm'
Making all in math
make[8]: Entering directory
`/users/rtems/src/toolchains/BUILD/i386-rtems4.9/i386-rtems4.9/soft-float/newlib/libm/math'
/users/rtems/src/toolchains/BUILD/i386-rtems4.9/./gcc/xgcc
-B/users/rtems/src/toolchains/BUILD/i386-rtems4.9/./gcc/ -nostdinc
-B/users/rtems/src/toolchains/BUILD/i386-rtems4.9/i386-rtems4.9/soft-float/newlib/
-isystem
/users/rtems/src/toolchains/BUILD/i386-rtems4.9/i386-rtems4.9/soft-float/newlib/targ-include
-isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include
-B/opt/rtems-4.9/i386-rtems4.9/bin/ -B/opt/rtems-4.9/i386-rtems4.9/lib/
-isystem /opt/rtems-4.9/i386-rtems4.9/include -isystem
/opt/rtems-4.9/i386-rtems4.9/sys-include -msoft-float
-DPACKAGE_NAME=\"newlib\" -DPACKAGE_TARNAME=\"newlib\"
-DPACKAGE_VERSION=\"1.16.0\" -DPACKAGE_STRING=\"newlib\ 1.16.0\"
-DPACKAGE_BUGREPORT=\"\" -I. -I../../../../../../../gcc-trunk/newlib/libm/math
-I../../../../../../../gcc-trunk/newlib/libm/math/../common -O2
-DMALLOC_PROVIDED -DEXIT_PROVIDED -DMISSING_SYSCALL_NAMES -DSIGNAL_PROVIDED
-DREENTRANT_SYSCALLS_PROVIDED -DHAVE_OPENDIR -DNO_EXEC -DHAVE_FCNTL
-fno-builtin -O2 -g -g -O2-msoft-float -c -o lib_a-sf_erf.o `test -f
'sf_erf.c' || echo '../../../../../../../gcc-trunk/newlib/libm/math/'`sf_erf.c
../../../../../../../gcc-trunk/newlib/libm/math/sf_erf.c: In function 'erfcf':
../../../../../../../gcc-trunk/newlib/libm/math/sf_erf.c:222: error:
unrecognizable insn:
(insn 33 32 34 6 ../../../../../../../gcc-trunk/newlib/libm/math/sf_erf.c:171
(set (reg:SF 84)
(plus:SF (reg:SF 85)
(reg:SF 85))) -1 (nil))
../../../../../../../gcc-trunk/newlib/libm/math/sf_erf.c:222: internal compiler
error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[8]: *** [lib_a-sf_erf.o] Error 1
--
Summary: ICE: in extract_insn, at recog.c:1990
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: i386-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
[Bug target/35083] ICE: in extract_insn, at recog.c:1990
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-05 05:11 --- Created an attachment (id=15097) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15097&action=view) preprocessed source of file producing ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
[Bug target/35088] New: ICE: in def_cfa_1, at dwarf2out.c:804
Today's (2008-02-05; rev. 132112) m68k-rtems*-gcc from gcc-trunk ICEs when
building rtems :
...
m68k-rtems4.9-gcc --pipe -B../../../lib/ -B../../../av5282/lib/ -specs
bsp_specs -qrtems -DPACKAGE_NAME=\"rtems-c-src\"
-DPACKAGE_TARNAME=\"rtems-c-src\" -DPACKAGE_VERSION=\"4.8.99.0\"
-DPACKAGE_STRING=\"rtems-c-src\ 4.8.99.0\"
-DPACKAGE_BUGREPORT=\"http://www.rtems.org/bugzilla\"; -I.
-I../../../../../../rtems.orig/c/src/libchip -isystem
../../../av5282/lib/include -D__INSIDE_RTEMS_BSD_TCPIP_STACK__ -Wall -m528x
-O2 -g -fomit-frame-pointer -MT network/libnetchip_a-i82586.o -MD -MP -MF
network/.deps/libnetchip_a-i82586.Tpo -c -o network/libnetchip_a-i82586.o `test
-f 'network/i82586.c' || echo
'../../../../../../rtems.orig/c/src/libchip/'`network/i82586.c
../../../../../../rtems.orig/c/src/libchip/network/i82586.c: In function
'i82586_start_transceiver':
../../../../../../rtems.orig/c/src/libchip/network/i82586.c:1942: internal
compiler error: in def_cfa_1, at dwarf2out.c:804
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
This ICE is reproducible for different -m<*> flags and for different source
files. However it only seems to occur when being combined with
-fomit-frame-pointer.
=> Wild guess: m68k's -fomit-frame-pointer handling is broken.
--
Summary: ICE: in def_cfa_1, at dwarf2out.c:804
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: m68k-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
[Bug target/35088] ICE: in def_cfa_1, at dwarf2out.c:804
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-05 14:32 --- Created an attachment (id=15100) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15100&action=view) preprocessed source of file producing ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
[Bug target/35072] h8300: ICE unwind-dw2-fde.c:650: error: unrecognizable insn
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-06 04:15 --- Created an attachment (id=15102) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15102&action=view) preprocessed source of file producing ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35072
[Bug target/35102] New: i386-*gcc: bad register name `%sil'
Today's (2008-02-06) gcc-trunk (rev 132144) fails to build rtems.
Seemingly it generates invalid assembly code:
# i386-rtems4.9-gcc --pipe -mtune=pentiumpro --pipe -DHAVE_CONFIG_H -I..
-I../../../lib/include -I../../../../../../rtems.orig/cpukit/libnetworking
-D_COMPILING_BSD_KERNEL_ -DKERNEL -DINET -DNFS -DDIAGNOSTIC -DBOOTP_COMPAT
-D_KERNEL -D__BSD_VISIBLE -Wall -fasm -g -O2 -MT
netinet/libnetworking_a-in_cksum.o -MD -MP -MF
netinet/.deps/libnetworking_a-in_cksum.Tpo -c -o
netinet/libnetworking_a-in_cksum.o `test -f 'netinet/in_cksum.c' || echo
'../../../../../../rtems.orig/cpukit/libnetworking/'`netinet/in_cksum.c
{standard input}: Assembler messages:
{standard input}:947: Error: bad register name `%sil'
gmake[2]: *** [netinet/libnetworking_a-in_cksum.o] Error 1
# i386-rtems4.9-as --version
GNU assembler (GNU Binutils) 2.18
The same piece of code builds fine with gcc-4.2.3
--
Summary: i386-*gcc: bad register name `%sil'
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: i386-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
[Bug target/35102] i386-*gcc: bad register name `%sil'
--- Comment #1 from corsepiu at gcc dot gnu dot org 2008-02-06 12:01 --- Created an attachment (id=15105) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15105&action=view) preprocessed source of file producing breakdown -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
[Bug target/35083] [4.3 regression] ICE: in extract_insn, at recog.c:1990
--- Comment #10 from corsepiu at gcc dot gnu dot org 2008-02-06 12:03 --- Thanks Uros, i386-rtems*-gcc now bootstraps again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
[Bug target/35073] illegal opcode movw for mcu avr3
--- Comment #4 from corsepiu at gcc dot gnu dot org 2008-02-11 17:17 --- The binutils patch mentioned in comment#2 seems to fix this issue. Today's gcc-trunk using binutils-2.18 with the patch applied doesn't expose this breakdown anymore. => The cause for this breakdown was using insufficient binutils. Bootstrapping/building gcc-4.3 for the avr requires binutils > 2.18. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35073
[Bug target/35071] bad instruction `do_itt eq'
--- Comment #7 from corsepiu at gcc dot gnu dot org 2008-02-14 17:26 --- Created an attachment (id=15150) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15150&action=view) patch implementing drow's proposal I have no idea what this patch actually does, but it at least lets arm-rtems*-gcc bootstrap ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35071
[Bug target/35088] ICE: in def_cfa_1, at dwarf2out.c:804
--- Comment #2 from corsepiu at gcc dot gnu dot org 2008-02-15 06:03 --- The patch Joseph Myers proposed in http://gcc.gnu.org/ml/gcc/2008-02/msg00264.html seems to solve this issue. -- corsepiu at gcc dot gnu dot org changed: What|Removed |Added CC||joseph at codesourcery dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
[Bug target/35088] ICE: in def_cfa_1, at dwarf2out.c:804
--- Comment #5 from corsepiu at gcc dot gnu dot org 2008-02-19 06:34 --- (In reply to comment #4) > Can this issue now be closed? IMO, yes. But I prefer to leave closing this PR to an m68k-specialist. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35088
[Bug bootstrap/43531] New: host files being used during cross compilation
with the gcc-4.5-20100325 (and predecessors) I am facing this kind of
builderrors when cross-building:
...
make[4]: Entering directory
`/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/h8300-rtems4.11/h8300h/libgcc'
# If this is the top-level multilib, build all the other
# multilibs.
# Recursively invoke make in the GCC directory to build any
# startfiles (for now). We must do this just once, passing
# it all the GCC_EXTRA_PARTS as simultaneous goal targets,
# so that rules which cannot execute simultaneously are properly
# serialized. We indirect through T_TARGET in case any multilib
# directories contain an equals sign, to prevent make from
# interpreting any of the goals as variable assignments.
# We must use cd && make rather than make -C, or else the stage
# number will be embedded in debug information.
T=`${PWDCMD-pwd}`/ \
&& cd ../../.././gcc \
&& make
GCC_FOR_TARGET="/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/./gcc/xgcc
-B/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/./gcc/
-B/opt/rtems-4.11/h8300-rtems4.11/bin/ -B/opt/rtems-4.11/h8300-rtems4.11/lib/
-isystem /opt/rtems-4.11/h8300-rtems4.11/include -isystem
/opt/rtems-4.11/h8300-rtems4.11/sys-include " \
MULTILIB_CFLAGS="-g -O2 -mh" \
T=$T \
T_TARGET="${T}crtbegin.o ${T}crtend.o ${T}crti.o ${T}crtn.o" \
T_TARGET
make[5]: Entering directory
`/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/gcc'
/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/./gcc/xgcc
-B/users/rtems/src/rpms/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.5.0/build/./gcc/
-B/opt/rtems-4.11/h8300-rtems4.11/bin/ -B/opt/rtems-4.11/h8300-rtems4.11/lib/
-isystem /opt/rtems-4.11/h8300-rtems4.11/include -isystem
/opt/rtems-4.11/h8300-rtems4.11/sys-include-c -g -O2 -mh -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -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../../gcc-4.5-20100325/gcc -I../../gcc-4.5-20100325/gcc/.
-I../../gcc-4.5-20100325/gcc/../include
-I../../gcc-4.5-20100325/gcc/../libcpp/include
-I../../gcc-4.5-20100325/gcc/../libdecnumber
-I../../gcc-4.5-20100325/gcc/../libdecnumber/dpd -I../libdecnumber
-DCLOOG_PPL_BACKEND\
../../gcc-4.5-20100325/gcc/config/h8300/h8300.c -o h8300.o
In file included from ../../gcc-4.5-20100325/gcc/config/h8300/h8300.c:25:0:
../../gcc-4.5-20100325/gcc/system.h:199:22: fatal error: strings.h: No such
file or directory
This error originates from this call to gcc carrying build-host include search
directories in its search path.
This shows in this case, because the build-host has both "strings.h" and
"string.h" while the target only has "string.h" and because the bogus include
search path causes compilation to pull-in a build-host's config.h (from
libcpp).
--
Summary: host files being used during cross compilation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #3 from corsepiu at gcc dot gnu dot org 2010-03-30 03:09 --- AFAICT, this bug affects all *-rtems* targets, if not _all_ targets, i.e. building target files uses host includes during bootstrap. But for some reasons I don't (yet) know, it only causes a breakdown for building some targets. So far I've encountered breakdowns for h8300-rtems* and the m32l-rtems* and know verified that building sparc-rtems* uses host-includes for building target-files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #4 from corsepiu at gcc dot gnu dot org 2010-03-30 03:22 --- > ... and the m32l-rtems* ... Typo, this should have been "... m32r-rtems*... " -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #6 from corsepiu at gcc dot gnu dot org 2010-03-30 14:11 --- (In reply to comment #5) > Not primary or secondary target. Well, then redefine your priorities - AFAICT, this bug affects cross building gcc for all targets - This isn't a regression, this is a show stopper! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #8 from corsepiu at gcc dot gnu dot org 2010-03-30 16:09 --- (In reply to comment #7) > At least please say how you configured gcc. We build one-tree-style build with newlib symlinked into gcc's sourcetree. Configuration from a sparc-rtems4.11-gcc: # /opt/rtems-4.11/bin/sparc-rtems4.11-gcc -v Using built-in specs. COLLECT_GCC=/opt/rtems-4.11/bin/sparc-rtems4.11-gcc COLLECT_LTO_WRAPPER=/opt/rtems-4.11/libexec/gcc/sparc-rtems4.11/4.5.0/lto-wrapper Target: sparc-rtems4.11 Configured with: ../gcc-4.5-20100325/configure --prefix=/opt/rtems-4.11 --bindir=/opt/rtems-4.11/bin --exec_prefix=/opt/rtems-4.11 --includedir=/opt/rtems-4.11/include --libdir=/opt/rtems-4.11/lib --libexecdir=/opt/rtems-4.11/libexec --mandir=/opt/rtems-4.11/share/man --infodir=/opt/rtems-4.11/share/info --datadir=/opt/rtems-4.11/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=sparc-rtems4.11 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --enable-threads --disable-lto --disable-plugin --enable-newlib-io-c99-formats --enable-languages=c,c++ Thread model: rtems gcc version 4.5.0 20100325 (RTEMS gcc-4.5.0-5.fc12/newlib-1.18.0-5.fc12) (GCC) RPMS/SRPMS can be found below ftp://ftp.rtems.org/pub/rtems/linux/4.11/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #11 from corsepiu at gcc dot gnu dot org 2010-03-30 16:50 --- (In reply to comment #9) > Maybe I am misreading the command invoked in Ralf's original report but it is > using xgcc which is the cross gcc: No, you haven't - It's likely a better analysis of the same issue I was observing xgcc being used with "target-includes" causing build failures for the m32r and h8300, because this pulls-in build-host config.h's into compiling target files. You are saying: h8300.c is a host file and should not be compiled with the cross-compiler. I think we are getting closer ... Could this be a CC vs. CC_FOR_BUILD issue? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #21 from corsepiu at gcc dot gnu dot org 2010-04-02 11:48
---
(In reply to comment #20)
> Is this fixed now?
Partially, I'd say.
The hard-breakdown due is gone, but now I am observing another bug:
T=`${PWDCMD-pwd}`/ \
&& cd ../../.././gcc \
&& make
GCC_FOR_TARGET="/users/rtems/src/toolchains/gcc-trunk/BUILD/./gcc/xgcc
-B/users/rtems/src/toolchains/gcc-trunk/BUILD/./gcc/ -nostdinc
-B/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/newlib/ -isystem
/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/newlib/targ-include
-isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include
-B/opt/rtems-4.11/h8300-rtems4.11/bin/ -B/opt/rtems-4.11/h8300-rtems4.11/lib/
-isystem /opt/rtems-4.11/h8300-rtems4.11/include
-isystem /opt/rtems-4.11/h8300-rtems4.11/sys-include " \
MULTILIB_CFLAGS="-g -O2 -mh" \
T=$T \
T_TARGET="${T}crtbegin.o ${T}crtend.o ${T}crti.o ${T}crtn.o" \
T_TARGET
make[5]: Entering directory `/users/rtems/src/toolchains/gcc-trunk/BUILD/gcc'
/users/rtems/src/toolchains/gcc-trunk/BUILD/./gcc/xgcc
-B/users/rtems/src/toolchains/gcc-trunk/BUILD/./gcc/ -nostdinc
-B/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/newlib/
-isystem
/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/newlib/targ-include
-isystem /users/rtems/src/toolchains/gcc-trunk/newlib/libc/include
-B/opt/rtems-4.11/h8300-rtems4.11/bin/ -B/opt/rtems-4.11/h8300-rtems4.11/lib/
-isystem /opt/rtems-4.11/h8300-rtems4.11/include -
isystem /opt/rtems-4.11/h8300-rtems4.11/sys-include-O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -I.
-I/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc
-I../../gcc
-I../../gcc//users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc
-I../../gcc/../include -I../../gcc/../libcpp/include
-I../../gcc/../libdecnumber -I../../gcc/../libdecnumber/dpd -I../libdecnumber
-DCLOOG_PPL_BACKEND
-g -O2 -mh -g0 -finhibit-size-directive -fno-inline -fno-exceptions
-fno-zero-initialized-in-bss -fno-toplevel-reorder -fno-tree-vectorize
-Dinhibit_libc \
-c ../../gcc/crtstuff.c -DCRT_BEGIN \
-o
/users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc/crtbegin.o
Note the
-I../../gcc//users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #24 from corsepiu at gcc dot gnu dot org 2010-04-07 05:58 --- (In reply to comment #23) > (In reply to comment #21) > > (In reply to comment #20) > > > Is this fixed now? > > > The hard-breakdown due is gone, but now I am observing another bug: > [...] > > Note the > > -I../../gcc//users/rtems/src/toolchains/gcc-trunk/BUILD/h8300-rtems4.11/h8300h/libgcc > > In what way is that a bug (honest question)? It's the concatenation of a relative dir with an absolute dir, pointing to an arbitrary location somewhere on the file system, ... i.e. it's completely bogus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug bootstrap/43531] [4.5 Regression] host files being used during cross compilation
--- Comment #27 from corsepiu at gcc dot gnu dot org 2010-04-07 13:38 --- (In reply to comment #26) > Fixed for 4.5.0 AFAICS. > Is the patch you are referring to in 4.5.0-RC-20100406? IIRC, snapshot 4.5-20100401 has had this issue, but I can't find any it anymore in my 4.5.0-RC-20100406 build logs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43531
[Bug target/43726] New: lm32-rtems* ICE
gcc-4.5.0-RC-20100406 triggers an ICE while building RTEMS:
...
lm32-rtems4.11-gcc --pipe -DHAVE_CONFIG_H -I..
-I../../cpukit/../../../lm32_evr/lib/include -DNO_SSI -DNO_SSL -DNO_CGI -O0
-g -Wall -Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
-MT l
../../../../../../c/src/../../cpukit/mghttpd/mongoose.c: In function
'handle_request_body':
../../../../../../c/src/../../cpukit/mghttpd/mongoose.c:3132:1: error:
unrecognizable insn:
(insn 333 332 334 47
../../../../../../c/src/../../cpukit/mghttpd/mongoose.c:3122 (set (reg:SI 157)
(subreg:SI (mem/c/i:DI (plus:SI (reg/f:SI 33 virtual-stack-vars)
(const_int -8 [0xfff8])) [0 content_len+0 S8
A64]) 4)) -1 (nil))
../../../../../../c/src/../../cpukit/mghttpd/mongoose.c:3132:1: internal
compiler error: in extract_insn, at recog.c:2103
Please submit a full bug report,
A gcc-4.4.3 based lm32-rtems*-gcc succeed in building the identical sources
without any complaint => regression
--
Summary: lm32-rtems* ICE
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: lm32-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug target/43726] lm32-rtems* ICE
--- Comment #1 from corsepiu at gcc dot gnu dot org 2010-04-12 11:52 --- Created an attachment (id=20363) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20363&action=view) *.i of the source file triggering the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug target/43726] lm32-rtems* ICE
--- Comment #3 from corsepiu at gcc dot gnu dot org 2010-04-12 12:31 --- (In reply to comment #2) > Did you have patches to get past > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527 or has it just gone away? Neither. This breakdown is with the rtems-4.11-lm32-rtems4.11-gcc rpm, i.e. it is built from the gcc-4.5.0-RC-20100406 candidate tarball. Also, unlike what you write in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43527#c1 (compiles at -O0, doesn't compile at -O1), this breakdown is with -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE
--- Comment #4 from corsepiu at gcc dot gnu dot org 2010-04-15 03:31 --- For the record: Bug is also present in gcc-4.5.0 (final). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug target/19421] [4.0/4.1 regression] ICE with soft-float on m68k
-- What|Removed |Added Known to fail|4.0.0 |4.0.0 4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/45208] New: powerpc-gcc -msdata breakdown on incomplete initializers
When compiling the code-snippet below with powerpc-*-gcc -msdata,
this error happens:
# powerpc-rtems4.11-gcc -c test.c -o test.o -msdata
test.c:10: error: rtems_filesystem_mount_table_size causes a section type
conflict
--- snip ---
int pipe (int __fildes[2] );
void Init( void )
{
int fd[2] = {0};
pipe( fd );
}
const int rtems_filesystem_mount_table_size = 1;
--- snip ---
This error does not happen, when
- compiling this snippet without -msdata
- expanding "int fd[2] = {0};" into "int fd[2] = {0,0};
I am able to reproduce this bug with GCC 4.2.4, 4.3.2, 4.4.4, 4.5.1,
all targetting "powerpc-rtems".
--
Summary: powerpc-gcc -msdata breakdown on incomplete initializers
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: powerpc-rtems*, powerpc-elf*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45208
[Bug bootstrap/43952] New: NetBSD _ANSI_H_ vs. _I386_ANSI_H_ and _X86_64_ANSI_H_
Building GCC-4.5.0 for targets i?86-netbsdelf5* and amd64-netbsdelf5*
chokes on issues related to ptrdiff_t and further types from stddef.h.
>From what I gather, the cause is these targets not providing
_ANSI_H nor _MACHINE_ANSI_H in their header but them using
_I386_ANSI_H_ rsp. _X86_64_ANSI_H_
This breaks the logic which supposed to handle the for
NetBSD targets in ginclude/stddef.h
--
Summary: NetBSD _ANSI_H_ vs. _I386_ANSI_H_ and _X86_64_ANSI_H_
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
GCC target triplet: {i?86,amd64}-*-netbsdelf5*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43952
[Bug bootstrap/43952] NetBSD _ANSI_H_ vs. _I386_ANSI_H_ and _X86_64_ANSI_H_
--- Comment #1 from corsepiu at gcc dot gnu dot org 2010-05-01 01:55 --- Created an attachment (id=20523) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20523&action=view) Define _MACHINE_ANSI_H if target defines _I386_ANSI_H_ || defined(_X86_64_ANSI_H_ This patch tries to to overcome this issue by defining _MACHINE_ANSI_ in gcc/ginclude/stddef.h if defined(_I386_ANSI_H_) || defined(_X86_64_ANSI_H_) is defined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43952
[Bug target/43726] [4.5/4.6 Regression] lm32-rtems* ICE
--- Comment #8 from corsepiu at gcc dot gnu dot org 2010-05-27 15:15 --- FWIW: I added your patch to the RTEMS lm32-gcc-4.5.0 toolchains. With this patch applied, the ICE during building RTEMS, I had experienced does not occur anymore. Compiling RTEMS at -O2 also seems to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43726
[Bug target/44793] [4.5/4.6 Regression] libgcc does not include t-ppccomm on rtems
--- Comment #6 from corsepiu at gcc dot gnu dot org 2010-07-05 03:30
---
(In reply to comment #5)
> rtems should be moved to the new style libgcc config and include
> ./config/rs6000/t-ppccomm .
Hmm. Doesn't RTEMS already do so?
>From config.gcc:
...
powerpc-*-rtems*)
tm_file="${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h
newlib-stdint.h rs6000/sysv4.h rs6000/eabi.h rs6000/e500.h rs6000/rtems.h
rtems.h"
extra_options="${extra_options} rs6000/sysv4.opt"
tmake_file="rs6000/t-fprules rs6000/t-fprules-fpbit rs6000/t-rtems
t-rtems rs6000/t-ppccomm"
;;
...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44793
[Bug target/44793] [4.5/4.6 Regression] libgcc does not include t-ppccomm on rtems
--- Comment #7 from corsepiu at gcc dot gnu dot org 2010-07-05 04:17 --- (In reply to comment #6) > (In reply to comment #5) > > rtems should be moved to the new style libgcc config and include > > ./config/rs6000/t-ppccomm . > > Hmm. Doesn't RTEMS already do so? Did you mean libgcc/config.host? In there, powerpc-*linux is the only target using libgcc/config/rs6000/t-ppccom -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44793
[Bug fortran/21143] New: cross-built gfortran installed as gfortran
Cross-building gfortran installs "gfortran" as $bindir/gfortran instead of $bindir/-gfortran My actual configuration (one-tree style, gcc-4.0.0 20050421 + newlib-cvs) configure ... --with-newlib --target=i386-rtems4.7 \ --enable-languages=c,c++,f95 -- Summary: cross-built gfortran installed as gfortran Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com GCC host triplet: any GCC target triplet: != build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
[Bug fortran/21143] cross-built gfortran installed as gfortran
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-21 16:20 --- Created an attachment (id=8704) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8704&action=view) Patch against 4.0.0 to fix this PR -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
[Bug target/17824] Hard-coded AS and LD in c4x.h
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-25 03:18 --- Fix commited as obvious to mainline, 4.0-branch and 3.4-branch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17824
[Bug target/17822] [3.4 only] avr: Hard-coded XXX_FOR_TARGET
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-25 04:18 --- Fix applied as obvious to mainline, 4.0-branch and 3.4-branch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|3.4.4 |--- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17822
[Bug fortran/21203] New: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
During bootstrapping gcc-4.0.0 (release) with f95 enabled, this segfault occurs:
#/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/gfortran
-B/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/
-nostdinc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/newlib/
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/newlib/targ-include
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/newlib/libc/include
-B/opt/rtems-4.7/h8300-rtems4.7/bin/ -B/opt/rtems-4.7/h8300-rtems4.7/lib/
-isystem /opt/rtems-4.7/h8300-rtems4.7/include -isystem
/opt/rtems-4.7/h8300-rtems4.7/sys-include -Wall -fno-repack-arrays
-fno-underscoring -c
../../../gcc-4.0.0/libgfortran/intrinsics/selected_int_kind.f90 -o
selected_int_kind.o
:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [selected_int_kind.lo] Error 1
gdb reveils this to be cause:
Program received signal SIGSEGV, Segmentation fault.
show_locus (offset=0, loc=0x833a17c) at ../../gcc-4.0.0/gcc/fortran/error.c:136
135 lb = loc->lb;
136 f = lb->file;
With
(gdb) print *loc
$10 = {nextc = 0x0, lb = 0x0}
I.e. a NULL pointer dereference in error.c:136
--
Summary: Segfault while compiling
libgfortran/intrinsics/selected_int_kind.f90
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: h8300-rtems4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-25 14:33 --- (In reply to comment #1) > Hmm. The origin of this issue seems to be f951's check's for REAL 8 (kind=8). The h8300 doesn't seem to provide this type and thereby seems to trigger a bug in f951's error handling. Bootstrapping avr-rtems w/ f95 enabled trips a similar or may-be the same bug (also a target which probably doesn't provide REAL 8). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-04-25 17:14 --- (In reply to comment #3) > (In reply to comment #2) > > > > The origin of this issue seems to be f951's check's for REAL 8 (kind=8). > > > > The h8300 doesn't seem to provide this type and thereby seems to trigger a > > bug > > in f951's error handling. > > The Fortran standard mandates that if REAL(4) is the default > real type, then there must be a REAL(8). I suspect gfortran > will not/never supply a software implementation of REAL(8). > We'll need to disable building of gfortran on targets that > do not provide 2 floating point types. I guess you are aware that for multilib'ed OSes (such as RTEMS) there can be multilib variants for whom types exist and others for whom types might not exit. I.e. disabling certain targets in general would impose unnecessarily strict restrictions. IMO, it would be more reasonable, to provide a "graceful degradation" on those targets-variants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug ada/21247] New: Cross-building gnat-4.0.0 requires native gnat-4.0.0
Bootstrapping a gcc-4.0.0/gnat cross-toolchain on FC3 using the native
FC3-gcc-3.4.3-22.fc3 toolchain fails with:
# ../gcc-4.0.0/configure --target=i386-rtems4.7 --enable-languages=c,ada
--disable-multilib --prefix=/opt/rtems-4.7 --with-gnu-as --with-gnu-ld
--with-newlib --with-system-zlib --disable-nls --enable-version-
specific-runtime-libs --enable-threads=rtems
...
make
...
gnatmake -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I.
-I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada
-u sdefault --GCC="gcc "
gcc -c -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I.
-I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada
sdefault.adb
gnatmake -c -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I.
-I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada
gnatmake --GCC="gcc -O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -gnatpg -gnata"
gcc -c -I./ -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I.
-I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada
-O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-gnatpg -gnata -I-
/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/gnatmake.adb
gcc -c -I./ -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I.
-I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada
-O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-gnatpg -gnata -I-
/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/gnatvsn.adb
gcc -c -I./ -I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/../adainclude
-I/usr/lib/gcc/i386-redhat-linux/3.4.3/adalib/ -I.
-I/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada
-O2 -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-gnatpg -gnata -I-
/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/make.adb
ali.ads:187:22: "Restrictions_Info" is undefined (more references follow)
gnatmake:
"/home/columbo/src/rpms/BUILD/rtems-4.7-i386-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/make.adb"
compilation error
make[3]: *** [gnatmake-re] Error 4
Using a native gcc-4.0.0, the same succeeds.
--
Summary: Cross-building gnat-4.0.0 requires native gnat-4.0.0
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot
com,laurent at guerby dot net
GCC host triplet: i686-redhat-linux
GCC target triplet: !=host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21247
[Bug ada/21276] New: Cross building gnats misses newlib headers
One-tree style bootstrapping a newlib-based cross GCC with ada enabled breaks
with this breakdown:
make[3]: Entering directory
`/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ada/rts'../../xgcc
-B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2 -fexceptions -DIN_RTS |sed
-e 's/-pedantic//g' -e 's/-Wtraditional//g'` -I. -I.. -I../..
-I/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada
-I/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../config
-I/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../../include
-I/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/..
-I./../.. adaint.c \
-o adaint.o
In file included from adaint.c:59:
/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../tsystem.h:90:19:
error: stdio.h: No such file or directory
/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../tsystem.h:93:23:
error: sys/types.h: No such file or directory
/users/columbo/src/rpms/BUILD/rtems-4.7-sparc-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/gcc/ada/../tsystem.h:96:19:
error: errno.h: No such file or directory
IMO, this indicates a bug inside of the GNAT configury, probably it is not aware
about newlib and therefore misses to acknowledge newlib's include directories
(Missing -I...)
Work around to this problem is to have a cross-gcc for the same target
previously installed, whose header sufficently match with the headers being used
by the build. In this case, bootstrapping seems to be using the already
installed headers instead of the headers of the GCC being build.
[I.e. 1. build and install gcc+newlib w/o gnat, then rebuild gcc w/ gnat].
--
Summary: Cross building gnats misses newlib headers
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot
com,laurent at guerby dot net,neroden at gcc dot gnu dot
org
GCC host triplet: any
GCC target triplet: !=host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21276
[Bug ada/21327] New: gnat_ugn.texi invalid @direntry
# /sbin/install-info --infodir=/opt/gnu/info \
/opt/gnu/info/gnat_ugn_unw.info
Produces this entry in /opt/gnu/info/dir
GNU Ada tools
* GNAT User's Guide (gnat_ugn_unw)
install-info --delete is not able to handle this:
# /sbin/install-info --delete --infodir=/opt/gnu/info \
/opt/gnu/info/gnat_ugn_unw.info
install-info: warning: no entries found for `/opt/gnu/info/gnat_ugn_unw.info';
nothing deleted
Afterwards, the gnat_ugn_unw entry in "dir" has not been deleted.
Apparently, "install-info" --delete expects a direntry of this kind:
* xxx: (yyy). zzz
/sbin/install-info --version
install-info (GNU texinfo) 4.7
--
Summary: gnat_ugn.texi invalid @direntry
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
[Bug other/21328] New: bogus permissions on files in CVS
These files in CVS bogusly carry executable permissions and should be
"chmod -x"'ed:
gcc/ada/a-chzla1.ads
gcc/ada/a-chzla9.ads
gcc/ada/a-lfztio.ads
gcc/ada/a-liztio.ads
gcc/ada/a-llfzti.ads
gcc/ada/a-llizti.ads
gcc/ada/a-sfztio.ads
gcc/ada/a-siztio.ads
gcc/ada/a-ssizti.ads
gcc/ada/a-stzbou.adb
gcc/ada/a-stzbou.ads
gcc/ada/a-stzfix.adb
gcc/ada/a-stzfix.ads
gcc/ada/a-stzhas.adb
gcc/ada/a-stzhas.ads
gcc/ada/a-stzmap.adb
gcc/ada/a-stzmap.ads
gcc/ada/a-stzsea.adb
gcc/ada/a-stzsea.ads
gcc/ada/a-stzsup.adb
gcc/ada/a-stzsup.ads
gcc/ada/a-stzunb.adb
gcc/ada/a-stzunb.ads
gcc/ada/a-swunau.adb
gcc/ada/a-swunau.ads
gcc/ada/a-szmzco.ads
gcc/ada/a-szunau.adb
gcc/ada/a-szunau.ads
gcc/ada/a-szunha.adb
gcc/ada/a-szunha.ads
gcc/ada/a-szuzti.adb
gcc/ada/a-szuzti.ads
gcc/ada/a-tiunio.ads
gcc/ada/a-wwunio.ads
gcc/ada/a-ztcoau.adb
gcc/ada/a-ztcoau.ads
gcc/ada/a-ztcoio.adb
gcc/ada/a-ztcoio.ads
gcc/ada/a-ztcstr.adb
gcc/ada/a-ztcstr.ads
gcc/ada/a-ztdeau.adb
gcc/ada/a-ztdeau.ads
gcc/ada/a-ztdeio.adb
gcc/ada/a-ztdeio.ads
gcc/ada/a-ztedit.adb
gcc/ada/a-ztedit.ads
gcc/ada/a-ztenau.adb
gcc/ada/a-ztenau.ads
gcc/ada/a-ztenio.adb
gcc/ada/a-ztenio.ads
gcc/ada/a-ztexio.adb
gcc/ada/a-ztexio.ads
gcc/ada/a-ztfiio.adb
gcc/ada/a-ztfiio.ads
gcc/ada/a-ztflau.adb
gcc/ada/a-ztflau.ads
gcc/ada/a-ztflio.adb
gcc/ada/a-ztflio.ads
gcc/ada/a-ztgeau.adb
gcc/ada/a-ztgeau.ads
gcc/ada/a-ztinau.adb
gcc/ada/a-ztinau.ads
gcc/ada/a-ztinio.adb
gcc/ada/a-ztinio.ads
gcc/ada/a-ztmoau.adb
gcc/ada/a-ztmoau.ads
gcc/ada/a-ztmoio.adb
gcc/ada/a-ztmoio.ads
gcc/ada/a-zttest.adb
gcc/ada/a-zttest.ads
gcc/ada/a-zzunio.ads
gcc/ada/g-utf_32.adb
gcc/ada/g-utf_32.ads
gcc/ada/g-zstspl.ads
gcc/ada/i-vxwork-x86.ads
gcc/ada/seh_init.c
--
Summary: bogus permissions on files in CVS
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21328
[Bug ada/21377] New: Error detected at a-stmaco.ads:65:4
While bootstrapping gcc-4.0.1 (20050503 pre) for sh-rtems4.7 using a native
vanilla GCC-4.0.0 on FC3:
../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg a-stmaco.ads -o a-stmaco.o
a-stmaco.ads: In function 'Ada.Strings.Maps.Constants._Elabs':
a-stmaco.ads:40: error: unrecognizable insn:
(insn:HI 98 97 99 1 a-stmaco.ads:68 (parallel [
(set (reg:HI 445)
(ashift:HI (reg:HI 446)
(reg:HI 447)))
(clobber (reg:SI 147 t))
]) -1 (insn_list:REG_DEP_TRUE 97 (nil))
(expr_list:REG_DEAD (reg:HI 447)
(expr_list:REG_UNUSED (reg:SI 147 t)
(expr_list:REG_EQUAL (ashift:HI (const_int 1 [0x1])
(reg:HI 447))
(nil)
+===GNAT BUG DETECTED==+
| 4.0.0 (RTEMS gcc-4.0.0-20050503/newlib-1.13.0--0.rc.20050503.1.fc3)
(sh-unknown-rtems4.7) GCC error:|
| in extract_insn, at recog.c:2020 |
| Error detected at a-stmaco.ads:65:4 |
| Please submit a bug report; see http://gcc.gnu.org/bugs.html.|
| Include the entire contents of this bug box in the report. |
| Include the exact gcc or gnatmake command that you entered. |
| Also include sources listed below in gnatchop format |
| (concatenated together with no headers between files). |
+==+
Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:387
make[3]: *** [a-stmaco.o] Error 1
make[3]: Leaving directory
`/users/columbo/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ada/rts'
make[2]: *** [gnatlib] Error 2
make[2]: Leaving directory
`/users/columbo/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ada'
make[1]: *** [gnatlib-plain] Error 2
make[1]: Leaving directory
`/users/columbo/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/sh-rtems4.7/liba
da'
make: *** [all-target-libada] Error 2
--
Summary: Error detected at a-stmaco.ads:65:4
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P2
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot
com,laurent at guerby dot net
GCC host triplet: i386-*
GCC target triplet: sh-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
[Bug ada/21377] Error detected at a-stmaco.ads:65:4
-- What|Removed |Added Known to fail||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21377
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-13 07:56 --- Created an attachment (id=8884) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8884&action=view) selected_int_kind.f90 As requested by Tobi, the selected_int_kind.f90 building h8300-rtems4.7 gcc-4.0.1 (pre 20050505) is ICE'ing on: /users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/gfortran -B/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/ -nostdinc -B/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/newlib/ -isystem /users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/newlib/targ-include -isystem /users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/newlib/libc/include -B/opt/rtems-4.7/h8300-rtems4.7/bin/ -B/opt/rtems-4.7/h8300-rtems4.7/lib/ -isystem /opt/rtems-4.7/h8300-rtems4.7/include -isystem /opt/rtems-4.7/h8300-rtems4.7/sys-include -Wall -fno-repack-arrays -fno-underscoring -c ../../../gcc-4.0.0/libgfortran/intrinsics/selected_int_kind.f90 -o selected_int_kind.o :0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[2]: *** [selected_int_kind.lo] Error 1 make[2]: Leaving directory `/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/libgfortran' make[1]: *** [all] Error 2 make[1]: Leaving directory `/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/h8300-rtems4.7/libgfortran' make: *** [all-target-libgfortran] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-13 07:59 --- Created an attachment (id=8885) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8885&action=view) selected_int_kind.inc Sorry, wrong file. This is the *.inc, Tobi requested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 06:30 --- (In reply to comment #11) > Ralf, it looks like no working integer type is found when building the > compiler. The h8300 is special wrt. integer types: >From a test script of mine: ... checking for char... yes checking size of char... 1 checking for short... yes checking size of short... 2 checking for int... yes checking size of int... 2 checking for long... yes checking size of long... 4 checking for long long... yes checking size of long long... 8 checking for float... yes checking size of float... 4 checking for double... yes checking size of double... 4 checking for long double... yes checking size of long double... 4 checking for void*... yes checking size of void*... 2 checking for int*... yes checking size of int*... 2 checking for long*... yes checking size of long*... 2 checking for __int8_t... yes checking size of __int8_t... 1 checking for __int16_t... yes checking size of __int16_t... 2 checking for __int32_t... yes checking size of __int32_t... 4 checking for __int64_t... yes checking size of __int64_t... 8 checking for int8_t... yes checking size of int8_t... 1 checking for int16_t... yes checking size of int16_t... 2 checking for int32_t... yes checking size of int32_t... 4 checking for int64_t... yes checking size of int64_t... 8 checking whether CHAR_BIT is declared... yes checking for bits in char... 8 Note: int8, int16, int32 and int64 all are available, it's just that the "usual" (bogus) assumptions * short==16bit * int==32bit * sizeof(void*)==sizeof(long) do not apply. Also note: This is a 16bit target, sizeof(void*)==16bit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 07:00 --- (In reply to comment #13) > I'll try again this weekend with the version of GMP on the laptop > and update GMP if it still fails. If you go to the GMP home page > there is a VERY big warning about problems with gcc 4.0. > > In looking over the history of this PR, comment #2 through me off > track because Fortran cannot be installed on a system with only a > single REAL kind. As I tried to express before, I think this PR actually trips several bugs at once. * A bug in error f95's handling, which probably causes the seg fault. The compiler simply must not seg fault. * A configuration problem: The configure scripts should be able to detect if a target doesn't meet its expectations. * f95 disqualifies ifselves from several embedded targets, if it can not be built/used on targets not supporting REAL8. IIRC, there even exist variants of major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. IMO, this is a design flaw, which should be in your interest to be circumvented. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 08:14 --- (In reply to comment #17) > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > > On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > > > * f95 disqualifies ifselves from several embedded targets, if it can > > not be > > built/used on targets not supporting REAL8. IIRC, there even exist > > variants of > > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > > IMO, this is a design flaw, which should be in your interest to be > > circumvented. > > > Also this is fortran requirement so technically it is not a design flaw > in gfortran but in the standard, I would complain to them instead of to > GCC about this. Yes we could circumvent this but that would be an extension. Free free to hang on closely to standards ... to me, this sounds as being stubborn and non-helpful to the fortran community, nor to GCC nor to embedded systems. I'd prefer GCC to hang on to practical demands and implications stemming from practice instead of being religious about standards ignoring practical implications. > And who would be using fortran for embedded targets anyways. Consider numerical applications on embedded systems using fortran libraries (image processing, control applications etc.) IMO, this is a hen-and-egg problem. Hardly anybody is using fortran on embedded targets because the language is not available for many targets, and it is not available for many targets, because the language is not able to support them/is too non-portable. In this particular case, I fail to understand why REAL8 must be available and I fail to understand why this type can't be made conditionally available. > g77 had the same issue until at least a 3.3 (or so) was released so having it > not fixed for a long time which was about 4 releases after the first official > GCC with g77 support (2.95). Well, you know, gcc-4.0.0 is a major GCC release, gfortran is new ... All this had caused me to have a look at known weeknesses in GCC. The result (not limited to fortran) esp. wrt. embedded targets, is pretty disillusioning. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-14 08:33 --- (In reply to comment #16) > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > > On May 14, 2005, at 3:00 AM, corsepiu at gcc dot gnu dot org wrote: > > > * f95 disqualifies ifselves from several embedded targets, if it can > > not be > > built/used on targets not supporting REAL8. IIRC, there even exist > > variants of > > major _targets_ (IIRC, powerpc, m68k) which do not support REAL8. > > IMO, this is a design flaw, which should be in your interest to be > > circumvented. > > Huh, PPC soft float supports REAL 8 still. Joel, do you recall the target in RTEMS which has 4-byte floats only? (We recently had an issue with it floating point context sizes related to it? IIRC, it had been a powerpc variant and we were forced to drop it because GCC doesn't support it. BTW1: IFAIK, there also exist sh-variants (target tuple *-single*) which don't have 8byte floats. RTEMS doesn't support them, so I've never tried to build fortran for then. -- What|Removed |Added CC||joel at oarcorp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-15
03:55 ---
(In reply to comment #20)
I think, I have isolated the bug:
BUG #1:
During bootstrap, libgfortran/Makefile tries to generate selected_int_kind.inc:
selected_int_kind.inc: $(srcdir)/mk-sik-inc.sh
$(SHELL) $(srcdir)/mk-sik-inc.sh '$(FCCOMPILE)' > $@
This fails due to a segfault in f951, but the Makefile does not halt on this
segfault and continues, leaving a corrupted selected_int_kind.inc behind.
The actual command that fails of part of running mk-sik-inc.sh is:
/users/columbo/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/f951
bla.f90 -quiet -dumpbase bla.f90 -auxbase bla -Wall -version -fno-repack-arrays
-fno-underscoring -o /tmp/cc6taI72.s
with this bla.f90 (The first code fragment being generated by mk-sik-inc.sh):
integer (kind=1) :: x
end
BUG #2
Debugging
f951 bla.f90 -quiet -dumpbase bla.f90 -auxbase bla -Wall -version
-fno-repack-arrays -fno-underscoring -o /tmp/cc6taI72.s
reveals this:
During its initialization, f951 calls gfc_init_kinds().
This succeeds to initialize all int types, but fails to find a mode for
kind=8/DIMode.
Near to its end it enters:
gfc_validate_kind (type=BT_REAL, kind=8, may_fail=0 '\0') at
../../gcc-4.0.0/gcc/fortran/trans-types.c:332
This fails (kind=8 N/A), therefore
gfc_internal_error("gfc_validate_kind(): Got bad kind")
is being entered, which calls
show_loci (&gfc_current_locus, NULL);
At this point, gfc_current_locus is
gdb) print gfc_current_locus
$24 = {nextc = 0x0, lb = 0x0}
With this value, show_loci dereferences a NULL pointer during computation of c1
at error.c:208:
198 show_loci (locus * l1, locus * l2)
199 {
200 int offset, flag, i, m, c1, c2, cmax;
201
202 if (l1 == NULL)
203 {
204 error_printf ("\n");
205 return;
206 }
207
208 c1 = l1->nextc - l1->lb->line;
209 c2 = 0;
(gdb) print *l1
$26 = {nextc = 0x0, lb = 0x0}
I.e. the origin of the segfault is show_loci's expectations not matching with
the actual contents of gfc_current_locus.
BUG #3:
libgfortran's configure should refuse to be compiled for setups not being
supported by it or silently degrade gracefully. IMO, simply not
compiling/disabling building libgfortran for such setups would be the simpliest
solutions
Note: I am not talking about disabing building fortran or libgfortran for whole
targets. For multilib'ed toolchains, libgfortran could be compilable/usable for
some multilib variants but not for all.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug target/21578] ICE in reload_cse_simplify_operands for Coldfire.
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-15 11:06 --- I can reproduce the bug -- What|Removed |Added CC||peter at the-baradas dot com Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||4.0.0 Known to work||3.2.3 Last reconfirmed|-00-00 00:00:00 |2005-05-15 11:06:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21578
[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-05-16 14:05 --- (In reply to comment #24) > Subject: Re: Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90 > > corsepiu at gcc dot gnu dot org wrote: > > > Joel, do you recall the target in RTEMS which has 4-byte floats only? I've found it. The RTEMS sources claim the "PowerPC 602" to have 4byte floats, only. > Note that the major demand the Fortran Standard places on DOUBLE > PRECISION is that it takes up twice the amount of storage. It also is > supposed to be of "higher precision", but that is a QOI issue. Cf. gcc-4.0-branch/fortran/trans-types.c ca. line 228ff: /* F95 14.6.3.1: A nonpointer scalar object of type double precision real ... occupies two contiguous numeric storage units. ... .. But at present there are no GCC targets for which a two-word type does not exist, so we just let gfc_validate_kind abort and tell us if something breaks. */ Well, the h8300 has 8byte types (seemingly long long), but it doesn't have 8byte floats. As the comment is on REAL8, ... there is something fishy in there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug target/18542] [3.4 regression] ICE: output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16 05:39 --- The avr and h8300 variants of this PR are tracked as PR18563 (avr) PR18564 (h8300) -- What|Removed |Added GCC target triplet|m68k-*-elf m68k-rtems* avr-*|m68k-*-elf m68k-rtems* |h8300-* | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18542
[Bug target/18563] ICE: output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16 05:35 --- I am reopening this PR to allow tracking this problem independent of PR18542. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18563
[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16 08:41 --- > > I am going to reopen them and remove the avr/h8300 from PR18542. > > "You can easily check that by testing if reverting the patch from comment #2 > helps. " Please read what I wrote in comment #10. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug target/18563] ICE: output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16 08:44 --- WTH are you permantently closing this PR? This PR is addressing the h8300 and one of the m68k-maintainers (Bernardo) had explicitly requested me to split the h8300-case from the m68k. Upset, Ralf -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18563
[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-14 13:58 --- PR18542 and this PR are not identical: Proof: * Compiling the example from comment #3 # m68k-rtems4.7-gcc -m68020 -O2 -o tmp.o -c pr18549.c pr18549.c: In function `foo': pr18549.c:31: internal compiler error: output_operand: invalid expression as operand # m68k-rtems4.7-gcc -m68000 -O2 -o tmp.o -c pr18549.c [No ICE] * Compling the example from PR18542: # m68k-rtems4.7-gcc -m68000 -O2 -o tmp.o -c cpuboot.c cpuboot.c: In function `boot_phase_1': cpuboot.c:8: internal compiler error: output_operand: invalid expression as operand # m68k-rtems4.7-gcc -m68020 -O2 -o tmp.o -c cpuboot.c cpuboot.c: In function `boot_phase_1': cpuboot.c:8: internal compiler error: output_operand: invalid expression as operand => The ICE from the example in PR15492 is independent of -m68020 Furthermore, no ICE occurs for the example from comment #3 with avr-*: # avr-rtems4.7-gcc -O2 -o tmp.o -c pr18549.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug target/18592] [3.3/3.4 regression] [m68k] ICE in output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16 05:33 --- (In reply to comment #11) > Comment #7 in PR18542 said that separate PR's > were going to be filed for avr and h8300. They were (PR18563 and PR18564), but somebody else has closed them as duplicates of PR15542 and merged the avr and h8300 variants of PR18542 back into PR18542. I am going to reopen them and remove the avr/h8300 from PR18542. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18592
[Bug target/18564] ICE: output_operand: invalid expression as operand
--- Additional Comments From corsepiu at gcc dot gnu dot org 2004-12-16 05:35 --- I am reopening this PR to allow tracking this problem independent of PR18542. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18564
[Bug target/14436] [3.3/3.4 regression] ICE building libgcc.a
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-10 15:45 --- (In reply to comment #11) > Are you sure it is even fixed? with gcc-4.0-20050109, the build fails with > this > message at what appears to be the same location in the compilation. > > ../../gcc-4.0.20050109/gcc/libgcc2.c: In function '__do_global_ctors': > ../../gcc-4.0.20050109/gcc/libgcc2.c:1674: internal compiler error: in > integer_all_onesp, at tree.c:995 Are you building w/ c++ enabled? Building g++ for the c4x has not worked as long as I can think back. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14436
[Bug rtl-optimization/18081] [3.4 only] Infinite memory allocation on -O3
-- What|Removed |Added CC||corsepiu at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
[Bug rtl-optimization/18081] [3.4 only] Infinite memory allocation on -O3
-- What|Removed |Added Known to work|4.0.0 |4.0.0 3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18081
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12 10:30 --- (In reply to comment #3) > What do you want the ABI for soft-float to be? > As RTEMS is probably the only user of -msoft-float, you get to choose. -msoft-float basically is just a synomym for -no-80387 (-MASK_80387 in i386.h), so there probably are more users. > Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want to supply > it yourself, or do you want to admit that all shipping processors have an > fpu and/or the os has an emulator? Neither. The actual problem is people using RTEMS on original i386dx's for whom previous verions of gcc had required -mtune=i386 -mno-80387 -no-fp-ret-in-387 rsp. -mcpu=i386 -msoft-float -no-fp-in-387. For other cpus, coupling -msoft-float with -no-fp-in-387 has proven not to be necessary. This all is the reason for RTEMS gcc to use this kind of multilibs: i386-rtems4.7-gcc --print-multi-lib .; m486;@mtune=i486 mpentium;@mtune=pentium mpentiumpro;@mtune=pentiumpro k6;@mtune=k6 athlon;@mtune=athlon soft-float;@msoft-float soft-float/nofp;@[EMAIL PROTECTED] m486/soft-float;@[EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug bootstrap/19393] New: Assembler error: branch out of range
Building today's (2005-01-12) gcc-CVS/trunk for arm-rtems4.7 fails in libiberty:
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/gcc/xgcc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/gcc/
-nostdinc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/arm-rtems4.7/newlib/
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/arm-rtems4.7/newlib/targ-include
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/gcc-3.4.4/newlib/libc/include
-B/opt/rtems-4.7/arm-rtems4.7/bin/ -B/opt/rtems-4.7/arm-rtems4.7/lib/ -isystem
/opt/rtems-4.7/arm-rtems4.7/include -isystem
/opt/rtems-4.7/arm-rtems4.7/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -mthumb
-I. -I../../../../gcc-3.4.4/libiberty/../include -W -Wall -Wtraditional
-pedantic ../../../../gcc-3.4.4/libiberty/regex.c -o regex.o
In file included from ../../../../gcc-3.4.4/libiberty/../include/xregex.h:26,
from ../../../../gcc-3.4.4/libiberty/regex.c:195:
../../../../gcc-3.4.4/libiberty/../include/xregex2.h:548: warning: ISO C90 does
not support `static' or type qualifiers in parameter array declarators
../../../../gcc-3.4.4/libiberty/regex.c: In function `xregcomp':
../../../../gcc-3.4.4/libiberty/regex.c:8043: warning: signed and unsigned type
in conditional expression
../../../../gcc-3.4.4/libiberty/regex.c: At top level:
../../../../gcc-3.4.4/libiberty/regex.c:8178: warning: unused parameter 'preg'
/tmp/ccPZWeWX.s: Assembler messages:
/tmp/ccPZWeWX.s:3602: Error: branch out of range
make[3]: *** [regex.o] Error 1
make[3]: Leaving directory
`/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc3.4.4newlib1.13.0/build/arm-rtems4.7/thumb/libiberty'
make[2]: *** [multi-do] Error 1
--
Summary: Assembler error: branch out of range
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: arm-rtems4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19393
[Bug bootstrap/19393] Assembler error: branch out of range
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12 10:38 --- Sorry, this is gcc-3.4-branch, not gcc-4.0.x ... -- What|Removed |Added Version|4.0.0 |3.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19393
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12
14:19 ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > What do you want the ABI for soft-float to be?
> > > As RTEMS is probably the only user of -msoft-float, you get to choose.
> > -msoft-float basically is just a synomym for -no-80387 (-MASK_80387 in
> > i386.h),
> > so there probably are more users.
>
> If you are tuly using soft-float, then the results can't be returned in the
> non-existent FPU registers so I have never understood from a practical matter
> why it didn't already imply avoiding returning values in FPU registers.
This is not how i386-gcc-rtems is set up until now.
> > > Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want to
> > > supply
> > > it yourself, or do you want to admit that all shipping processors have an
> > > fpu and/or the os has an emulator?
> > Neither.
>
> Richard gave four options.
>
> (1) -msoft-float to imply -mno-fp-ret-in-387
IMO, this proposal is meaningless unless
-mno-80387 also is changed to imply -mno-fp-ret-in-387.
> (2) supply "it" yourself (?? do you mean explicitly state
> -mno-fp-ret-in-387)
> (3) admit that all shipping processors have an FPU
> (4) add an FPU emulator to RTEMS
>
> (3) is quite an assertion.
ACK, this is not feasible.
> (4) is not likely to happen.
Hmm? What is -msoft-float -mno-fp-ret-in-387 using, then?
> This leaves us with (1).
Cf. above.
Theoretically, letting -msoft-float imply -mno-fp-ret-in-387 should provide a
multilib variant applicable to i386dx's.
> > The actual problem is people using RTEMS on original i386dx's for whom
> > previous
> > verions of gcc had required -mtune=i386 -mno-80387 -no-fp-ret-in-387 rsp.
> > -mcpu=i386 -msoft-float -no-fp-in-387.
> >
> > For other cpus, coupling -msoft-float with -no-fp-in-387 has proven not to
> > be
> > necessary.
>
> I checked the i386ex BSPs and one used
> -msoft-float -mno-fp-ret-in-387
The pc386dx BSP uses this one.
> and the other only used -msoft-float.
> The pc386dx BSP uses both options.
No, the pc386 BSP uses this one.
The source code is identical, the only differnence is -mno-fp-ret-in-387
> I am willing to go with (1). Can this be done all the time
> for -msoft-float? Just change i386.h like this:
>
> { "soft-float", (-MASK_80387|-MASK_FLOAT_RETURNS|, N_("Do not
> use hardware fp")
> }, \
>
> Is that enough?
To provide RTEMS with a work-around, yes, this should be sufficient.
However, cf. above. IMO, this is not sufficient for GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug c++/19399] New: gthread_recursive_mutex's missing
GCC 4.0 has broken rtems thread support for all targets:
# configure --enable-languages=c,c++ --enable-threads=rtems\
[more options]
...
# make
...
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/xgcc
-shared-libgcc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/
-nostdinc++
-L/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/libstdc++-v3/src
-L/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/libstdc++-v3/src/.libs
-nostdinc
-B/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/newlib/
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/newlib/targ-include
-isystem
/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/newlib/libc/include
-B/opt/rtems-4.7/arm-rtems4.7/bin/ -B/opt/rtems-4.7/arm-rtems4.7/lib/ -isystem
/opt/rtems-4.7/arm-rtems4.7/include -isystem
/opt/rtems-4.7/arm-rtems4.7/sys-include
-I/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/libstdc++-v3/../gcc
-I/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/libstdc++-v3/include/arm-rtems4.7
-I/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/arm-rtems4.7/libstdc++-v3/include
-I/users/rtems/src/rpms/BUILD/rtems-4.7-arm-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/gcc-4.0.0/libstdc++-v3/libsupc++
-O2 -g -O2 -g -O2 -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -fdiagnostics-show-location=once -c
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc -o guard.o
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:51: error:
'__gthread_recursive_mutex_t' does not name a type
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:62: error:
'__gthread_recursive_mutex_t' does not name a type
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc: In static member function
'static void::static_mutex::lock()':
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:81: error: 'mutex' was not
declared in this scope
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:81: error:
'__gthread_recursive_mutex_lock' was not declared in this scope
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc: In static member function
'static void::static_mutex::unlock()':
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:86: error: 'mutex' was not
declared in this scope
../../../../gcc-4.0.0/libstdc++-v3/libsupc++/guard.cc:86: error:
'__gthread_recursive_mutex_unlock' was not declared in this scope
Without having looked into details, something in GCC seems to have changed which
silently breaks gthr-rtems.h.
--
Summary: gthread_recursive_mutex's missing
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at gcc dot gnu dot
org
GCC target triplet: *-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19399
[Bug c++/19399] gthread_recursive_mutex's missing
-- What|Removed |Added Known to fail||4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19399
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12 15:02 --- (In reply to comment #7) > (In reply to comment #6) > > > If you are tuly using soft-float, then the results can't be returned in > > > the > > > non-existent FPU registers so I have never understood from a practical > > > matter > > > why it didn't already imply avoiding returning values in FPU registers. > > This is not how i386-gcc-rtems is set up until now. > > Right but there is nothing preventing it from changing and all BSPs with > recent test reports specify -mno-fp-ret-in-387 flag anyway. > Unfortunately, I think soft-float doesn't completely eliminate all uses of > the FPU so you have to add the no-fp-ret-in-387 argument. True, but ... -msoft-float == -mno-80387 The RTEMS user using the i386dx had proven this not to work on original i386dx w/o i387. However, he has proven -msoft-float -mno-fp-ret-in-387 to work for him. => IMO, the actual fix would be to merge MASK_FLOAT_RETURNS into MASK_80387 and to abandon MASK_FLOAT_RETURNS. > Richard has said RTEMS is > the only target who cares about soft-float. I don't agree to his statement. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug target/19399] [4.0 Regression] mutexes support broken
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-12 23:57 --- (In reply to comment #6) > (In reply to comment #3) > What do you think of them? pr19399-try2.diff looks good to me. I've just launched local test-builds, nevertheless, OK to commit, IMO. I haven't looked into rtems-gxx_wrappers.diff, yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19399
[Bug target/19421] New: [4.0 regression] ICE
The code from the attachment cause m68k-rtems-gcc to ICE if being compiled with
-msoft-float -O2.
# m68k-rtems4.7-gcc -O2 -msoft-float -o tmp.o -c paranoia.c
paranoia.c: In function 'paranoia':
paranoia.c:1238: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
# m68k-rtems4.7-gcc --version
m68k-rtems4.7-gcc (GCC) 4.0.0 20050112 (experimental)
Optimization levels less than -02 do not trigger the ICE.
--
Summary: [4.0 regression] ICE
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: cjohns at cybertec dot com dot au,gcc-bugs at gcc dot
gnu dot org,joel at oarcorp dot com
GCC target triplet: m68k-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19421] [4.0 regression] ICE
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13 10:18 --- Created an attachment (id=7948) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7948&action=view) Code to reproduce the ICE Sorry for the size of the example (stripped down from RTEMS paranoia.c), but I have not been able to further reduce it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19421] [4.0 regression] ICE
-- What|Removed |Added Known to fail||4.0.0 Known to work||3.2.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13 13:31 --- (In reply to comment #11) > (In reply to comment #10) > One thing that I notice about this is that -msoft-float and -mhard-float are > no longer inverses. Good point. How about these alternatives: 1. Systematically substitute all occurences of MASK_80387 with (MASK_80387|MASK_FLOAT_RETURN) in i386.h. This would keep -msoft-float and -mno-80387, rsp. -mno-soft-float, -mhard-float and -m80387 as synonyms. IMO, this would be the least intrusive way of a proper fix. 2. Completely eliminate MASK_FLOAT_RETURN and to use MASK_80837, instead. This would be a pretty radical way, I am not sure about its consquences, but I don't expect it to do much harm. 3. Keep -[no-]hard-float, -m[no-]80387 and -m[no-]fp-ret-in-387 as they currently are, but only change soft-float to (MASK_80387|MASK_FLOAT_RETURN) and -mno-soft-float to -(MASK_80387|MASK_FLOAT_RETURN). This would satisfy RTEMS without disturbing other targets/OSes (We'd have to change our multilibs, but this wouldn't be an issue). I'd consider this to be a more a hack than an actual fix ;) 4. Fix the cause of this PR. I.e. prevent GCC from generating FPU code in the case this breakdown occurred. Unfortunately, I don't know the cause nor how to work around it. > Perhaps it would be better to modify override_options to > notice when, after all options are processed, that MASK_80387 is off and then > turn off MASK_FLOAT_RETURNS to match. I don't understand. Could you elaborate? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug target/19399] [4.0 Regression] mutexes support broken
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-13 17:04 --- Patches applied to trunk. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19399
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
-- What|Removed |Added Summary|[4.0 regression] ICE with |[4.0 regression] ICE with |solf-float on m68k |soft-float on m68k http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-14 15:15 --- (In reply to comment #6) I on Fedora Core 3 and am using FC3's toolchain. > What options are used to configure gcc, maybe it has something to do > with that (what I mean a different default CPU is done). > I configured with "../configure --target=m68k-rtems4.7" /opt/rtems-4.7/bin/m68k-rtems4.7-gcc -v Using built-in specs. Configured with: ../gcc-4.0.0/configure --prefix=/opt/rtems-4.7 --mandir=/opt/rtems-4.7/man --infodir=/opt/rtems-4.7/info --build=i686-redhat-linux-gnu --host=i686-redhat-linux-gnu --target=m68k-rtems4.7 --with-gnu-as --with-gnu-ld --with-newlib --verbose --with-system-zlib --disable-nls --enable-version-specific-runtime-libs --enable-threads=rtems --enable-languages=c,c++ Thread model: rtems gcc version 4.0.0 20050112 (experimental) I am building gcc one-tree-style with newlib-CVS merged via symlinks into GCC's source-tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug c++/19447] New: unknown conversion type character `q' in format
When building today's (2005-01-14) gcc-trunk for different (cross-) targets on FC3, I am seeing many (several 10ths) warnings of this kind: ... gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fno-common -DHAVE_CONFIG_H-I. -Icp -I../../gcc-4.0.0/gcc -I../../gcc-4.0.0/gcc/cp -I../../gcc-4.0.0/gcc/../include -I../../gcc-4.0.0/gcc/../libcpp/include ../../gcc-4.0.0/gcc/cp/call.c -o cp/call.o ../../gcc-4.0.0/gcc/cp/call.c: In function `build_new_op': ../../gcc-4.0.0/gcc/cp/call.c:3765: warning: unknown conversion type character `q' in format ../../gcc-4.0.0/gcc/cp/call.c:3765: warning: too many arguments for format ../../gcc-4.0.0/gcc/cp/call.c: In function `enforce_access': ../../gcc-4.0.0/gcc/cp/call.c:4068: warning: unknown conversion type character `q' in format ../../gcc-4.0.0/gcc/cp/call.c:4068: warning: too many arguments for format ../../gcc-4.0.0/gcc/cp/call.c:4070: warning: unknown conversion type character `q' in format ../../gcc-4.0.0/gcc/cp/call.c:4070: warning: too many arguments for format ../../gcc-4.0.0/gcc/cp/call.c:4072: warning: unknown conversion type character `q' in format ../../gcc-4.0.0/gcc/cp/call.c:4072: warning: too many arguments for format ... In my understanding, this is the native gcc (gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) complaining about GCC-4.0.0 using "%q" as a format string. I haven't tried, but IMO this probably results into GCC/c++ using non-functional format strings. -- Summary: unknown conversion type character `q' in format Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: corsepiu at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: 386-redhat-linux-gnu GCC host triplet: i386-redhat-linux-gnu GCC target triplet: *-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19447
[Bug c++/19447] unknown conversion type character `q' in format
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-15 04:32 --- (In reply to comment #1) > Invalid, the warnings were correct for compiling 3.4.x but are not correct > when compiling 4.0.0 but you > have to compile with 4.0.0 to get correct warnings for this case. Are you trying to say * 3.4.x is emitting bogus warnings? Then this is a gcc-3.4.x bug. * building 4.0.0 requires a native gcc-4.0.0? This would qualify as a serious GCC-4.0 regression. I both cases this is a bug. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19447
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-17 16:09 --- (In reply to comment #13) > As for (4), what do you think the problem *is* anyway? To me the problem is: "i386-rtems-gcc-4.0 ices when building the '-msoft-float -mtune=i386' multilib variant." Now the observation is, the '-soft-float -mtune=i386 -fno-fp-ret-in-387' multilib variant to be building fine. >From this I conclude, that i386-*gcc-4.0 probably has a bug somewhere which causes it to generate incorrect code for '-msoft-float -mtune=i386'. I.e. I would be satisfied if we can manage to find a way to let the "-msoft-float -mtune=i386" multilib variant imply -fno-fp-ret-in-387". My proposals above were along the consideration of * Users reported "-fno-80387" not to be sufficient for real i386s w/o i387 * gcc-4.0 also seems to have encountered problems with it .. so why not merge "-mno-80387" and "-no-fp-ret-in-387"? > It's the fact > that "fxch" is marked TARGET_80387, and the only reason *that* got emitted > is to put the return value in the right place for MASK_FLOAT_RETURN. Duh. Sorry, I am as much an i386 expect to be able to comment on this. > And my suggestion is to add > > if (!TARGET_80387) > target_flags &= ~MASK_FLOAT_RETURNS; > > somewhere in the middle of override_options. Preferably near the other > bits that talk about fpmath etc. I need some more time to think about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
[Bug target/19378] [4.0 Regression] ICE during bootstrap compiling __fixdfdi
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-18 03:02 --- (In reply to comment #4) > Patch here: <http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00834.html>. This patch lets building succeed for avr-rtems*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19378
[Bug target/19528] New: [4.0 regression] missing ra.h
Today's (2005-01-19) gcc trunk does not build for sh-rtems*:
...
make[1]: Entering directory
`/users/rtems/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc'
gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fno-common
-DHAVE_CONFIG_H-I. -I. -I../../gcc-4.0.0/gcc -I../../gcc-4.0.0/gcc/.
-I../../gcc-4.0.0/gcc/../include -I../../gcc-4.0.0/gcc/../libcpp/include \
../../gcc-4.0.0/gcc/config/sh/sh.c -o sh.o
../../gcc-4.0.0/gcc/config/sh/sh.c:50:16: ra.h: No such file or directory
../../gcc-4.0.0/gcc/config/sh/sh.c: In function `push_regs':
../../gcc-4.0.0/gcc/config/sh/sh.c:5049: warning: implicit declaration of
function `hard_regs_intersect_p'
make[1]: *** [sh.o] Error 1
make[1]: Leaving directory
`/users/rtems/src/rpms/BUILD/rtems-4.7-sh-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc'
As it seems to me, this patch might have broken the sh:
2005-01-17 Paolo Bonzini <[EMAIL PROTECTED]>
* common.opt (-fnew-ra): Remove.
* ra*.*: Remove.
* toplev.h (flag_new_regalloc): Remove.
* Makefile.in (ra*.*): Don't mention.
* passes.c (rest_of_handle_new_regalloc): Remove.
(rest_of_handle_combine, rest_of_compilation): Always consider
flag_new_regalloc as false.
* doc/invoke.texi: Don't document -fnew-ra.
--
Summary: [4.0 regression] missing ra.h
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: corsepiu at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org,joel at oarcorp dot com
GCC target triplet: sh-rtems, sh-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
