[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 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 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 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 machine/ansi.h header but them using
_I386_ANSI_H_ rsp. _X86_64_ANSI_H_
This breaks the logic which supposed to handle the machine/ansi.h 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=20523action=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 #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/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=20363action=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 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 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 #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 #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 #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] 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 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/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 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=15150action=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/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/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=15105action=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/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=15100action=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=15102action=view) preprocessed source of file producing ICE -- 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=15097action=view) preprocessed source of file producing ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35083
[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/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/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 URL: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 URL: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/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 URL: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=10636action=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 URL:http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25780
[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 URL: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/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 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 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/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-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 (During initialization\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 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=8884action=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 built-in:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [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=8885action=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 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 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/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/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 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
built-in:0: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
make[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 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/21143] New: cross-built gfortran installed as gfortran
Cross-building gfortran installs gfortran as $bindir/gfortran instead of $bindir/target-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=8704action=view) Patch against 4.0.0 to fix this PR -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21143
[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 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 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/19920] [4.0 Regression] avr target build broken by recent 'DC' type update to libgcc2
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-02-14 11:12 --- Regression confirmed for avr-*-rtems* (20050214). -- What|Removed |Added CC||ralf dot corsepius at rtems ||dot org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-02-14 11:12:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
[Bug target/19949] New: [4.0 Regression] error: unable to emulate 'DC'
Bootstrapping h8300-rtems* (GCC-4.0 - 20050214) fails with: /users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc/xgcc -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 -O2 -I../../gcc-4.0.0/gcc/../newlib/libc/sys/rtems/include -DIN_GCC -DCROSS_COMPILE -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-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 -DL_muldi3 -c ../../gcc-4.0.0/gcc/libgcc2.c -o libgcc/./_muldi3.o In file included from ../../gcc-4.0.0/gcc/libgcc2.c:56: ../../gcc-4.0.0/gcc/libgcc2.h:96: error: unable to emulate 'DC' make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: Leaving directory `/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/users/rtems/src/rpms/BUILD/rtems-4.7-h8300-rtems4.7-gcc-newlib-gcc4.0.0newlib1.13.0/build/gcc' make: *** [all-gcc] Error 2 AFAIS, this breakdown is strongly related to PR 19920. -- Summary: [4.0 Regression] error: unable to emulate 'DC' 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: h8300-rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19949
[Bug target/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-14 12:01 --- (In reply to comment #7) *** Bug 19949 has been marked as a duplicate of this bug. *** OK, then for completeness: Regression confirmed for h8300-*-rtems* (GCC-4.0 20050214). -- What|Removed |Added CC|ralf dot corsepius at rtems |joel at oarcorp dot com |dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19920
[Bug other/14554] libffi: ASM error
-- What|Removed |Added CC||cjohns at cybertec dot com ||dot au http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14554
[Bug target/19749] Coldfire ICE at -O2 or higher
-- What|Removed |Added CC||ralf dot corsepius at rtems ||dot org GCC target triplet|m86k-rtems |m68k-rtems http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19749
[Bug target/19663] New: sparc.h's LINK_GCC_C_SEQUENCE_SPEC lacks generality
The LINK_GCC_C_SEQUENCE_SPEC provided by gcc/config/sparc/sparc.h is not applicable to sparc-rtems. IMO, sparc.h's LINK_GCC_C_SEQUENCE_SPEC probably is specific to solaris and not generally applicable. May-be, it's an historic artefact. I am going to apply the patch below to GCC-trunk to work-around this issue for rtems. Index: rtemself.h === RCS file: /cvs/gcc/gcc/gcc/config/sparc/rtemself.h,v retrieving revision 1.13 diff -u -r1.13 rtemself.h --- rtemself.h 24 Jan 2005 21:31:52 - 1.13 +++ rtemself.h 28 Jan 2005 05:38:02 - @@ -29,3 +29,6 @@ builtin_assert (system=rtems);\ } \ while (0) + +/* Use the default */ +#undef LINK_GCC_C_SEQUENCE_SPEC -- Summary: sparc.h's LINK_GCC_C_SEQUENCE_SPEC lacks generality 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: sparc-rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19663
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-23 12:26 --- Created an attachment (id=8044) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8044action=view) Example 2 to reproduce the ICE There seems to be some improvement on this PR. pr19421.c doesn't trigger the ICE anymore with 4.0.0 as of 20050121. The original code, pr19421.c had been derived from, however still ICEs for certain CFLAGS. I am attaching a somewhat rawer version (pr19421-1.c) of the original code. For me, compiling pr19421-1.c ICEs for # 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 but doesn't ICE for # m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O1 -msoft-float and # m68k-rtems4.7-gcc -o tmp.o -c pr19421-1.c -O2 # m68k-rtems4.7-gcc --version m68k-rtems4.7-gcc (GCC) 4.0.0 20050121 (experimental) Also, this ICE doesn't seem to depend on the version of host compiler being used to compile m68k-rtems4.7-gcc. On FC3, both, a gcc-3.4.2 compiled m68k-rtems4.7-gcc and a gcc4.0.0 compiled m68k-rtems-gcc, expose the same behavior. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19421] [4.0 regression] ICE with soft-float on m68k
-- What|Removed |Added Attachment #7948 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19421
[Bug target/19548] [3.4/4.0 regression] RTEMS CPP specs not merged from 3.2/3.2 branches
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-21
10:04 ---
(In reply to comment #2)
commit was not there so I would assume this could clarify as obvious.
OK, thanks.
However, one thought:
In gcc 3.4 CPP_OS_RTEMS_SPEC had been part of svr4.h.
What do you think about moving CPP_OS_RTEMS_SPEC into rs6000/rtems.h, i.e. about
a applying this patch to gcc-4.0:
Index: gcc/config/rs6000/rtems.h
===
RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rtems.h,v
retrieving revision 1.20
diff -u -r1.20 rtems.h
--- gcc/config/rs6000/rtems.h 17 Oct 2004 18:09:44 - 1.20
+++ gcc/config/rs6000/rtems.h 21 Jan 2005 10:02:12 -
@@ -38,3 +38,20 @@
#undef CPP_OS_DEFAULT_SPEC
#define CPP_OS_DEFAULT_SPEC %(cpp_os_rtems)
+
+#define CPP_OS_RTEMS_SPEC \
+%{!mcpu*: %{!Dppc*: %{!Dmpc*: -Dmpc750} } }\
+%{mcpu=403: %{!Dppc*: %{!Dmpc*: -Dppc403} } } \
+%{mcpu=505: %{!Dppc*: %{!Dmpc*: -Dmpc505} } } \
+%{mcpu=601: %{!Dppc*: %{!Dmpc*: -Dppc601} } } \
+%{mcpu=602: %{!Dppc*: %{!Dmpc*: -Dppc602} } } \
+%{mcpu=603: %{!Dppc*: %{!Dmpc*: -Dppc603} } } \
+%{mcpu=603e: %{!Dppc*: %{!Dmpc*: -Dppc603e} } } \
+%{mcpu=604: %{!Dppc*: %{!Dmpc*: -Dmpc604} } } \
+%{mcpu=750: %{!Dppc*: %{!Dmpc*: -Dmpc750} } } \
+%{mcpu=821: %{!Dppc*: %{!Dmpc*: -Dmpc821} } } \
+%{mcpu=860: %{!Dppc*: %{!Dmpc*: -Dmpc860} } }
+
+#undef SUBSUBTARGET_EXTRA_SPECS
+#define SUBSUBTARGET_EXTRA_SPECS \
+ { cpp_os_rtems,CPP_OS_RTEMS_SPEC }
It would avoid polluting other targets' spec with RTEMS details while it should
not make a difference for powerpc-rtems.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19548
[Bug target/19548] [3.4/4.0 regression] RTEMS CPP specs not merged from 3.2/3.2 branches
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-22 03:13 --- Patch shown in comment #3 commited to gcc-trunk and gcc-3_4-branch. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19548
[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-20 13:33 --- (In reply to comment #12) FYI Ralf tracked down one warning we got linking sparc apps to this: I think the cause is sparc/sparc.h's LINK_GCC_C_SEQUENCE_SPEC: #define LINK_GCC_C_SEQUENCE_SPEC %G %L %G %L The RTEMS LIB_SPEC includes a -T linkcmds which can only show up in the final ld command once. The double inclusion of %L seems to appear and disappear from release to release. 3.2.x did not have it. We had a local fix for 3.*. I don't know which target needs this but if it is important to them, FWIW: IMO, all targets implcitly relying on the sparc/sparc.h's LINK_GCC_C_SEQUENCE_SPEC are broken. Grep'ing the sources reveals all major sparc-targets to override this LINK_GCC_C_SEQUENCE_SPEC, so I don't expect removing it there to do much harm. Probably, %G %L %G %L also is SunOS/Solaris specific and actually does not belong into sparc.h. Also, I fail to understand how LINK_GCC_C_SEQUENCE_SPEC can be target-cpu specific. It is target-os specific. we can override it in rtemself.h. I don't really like this. IMO, the sparc backend suffers from its SunOS/Solaris history and should be cleaned up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19364
[Bug bootstrap/19364] [4.0 Regression] embedded sparc does not bootstrap
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-20
16:11 ---
(In reply to comment #16)
FWIW: IMO, all targets implicitly relying on the sparc/sparc.h's
LINK_GCC_C_SEQUENCE_SPEC are broken.
I don't think so. I can tell you for sure that Solaris is not broken.
Grep'ing the sources reveals all major sparc-targets to override this
LINK_GCC_C_SEQUENCE_SPEC, so I don't expect removing it there to do much
harm.
Note the Linux variant: %{static:--start-group} %G %L %{static:--end-group}
which means that the group %G %L is repeatedly searched.
Hmm, we have
--start-group -lrtemsbsp -lrtemscpu -lc -lgcc --end-group
in all of RTEMS-gcc specs. This might explain, why we don't see this issue.
Of course the Sun
linker (at least the ancient versions) is not that smart so we need to use the
double inclusion by default.
Note _Sun_, not _sparc_.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19364
[Bug target/19548] [3.4, 4.0 regression} RTEMS CPP specs not merged from 3.2/3.2 branches
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-21 01:08 --- The required bits are on gcc-3_2-branch and gcc-3_3-branch, but are missing from gcc-3_4-branch and gcc-CVS-trunk. -- What|Removed |Added Known to fail||3.4.3 4.0.0 Known to work||3.2.3 3.3.4 Summary|RTEMS CPP specs not merged |[3.4, 4.0 regression} RTEMS |from 3.2/3.2 branches |CPP specs not merged from ||3.2/3.2 branches http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19548
[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
[Bug bootstrap/19529] New: [4.0 regression] sh-rtems multilibs broken
RTEMS is relying on the set of multilibs having been used by default before gcc-4.0.0, i.e. # sh-rtems-gcc --print-multi-lib .; ml;@ml m2;@m2 m3e;@m3e m4-single-only;@m4-single-only m4-single;@m4-single m4;@m4 ml/m2;@[EMAIL PROTECTED] ml/m3e;@[EMAIL PROTECTED] ml/m4-single-only;@[EMAIL PROTECTED] ml/m4-single;@[EMAIL PROTECTED] ml/m4;@[EMAIL PROTECTED] # sh-rtems-gcc --version sh-rtems-gcc (GCC) 3.2.3 Some time between 3.2.3 and gcc-4.0 the default set of multilibs has changed into ml/mb. These are do not meet RTEMS requirements and are unsuiteable for RTEMS. I plan to submit/commit suiteable patches to config.gcc and config/sh/t-rtems to provide custom multilibs which match the old default. -- Summary: [4.0 regression] sh-rtems multilibs broken 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: sh-rtems* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19529
[Bug target/19528] [4.0 regression] missing ra.h
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-19 16:35 --- (In reply to comment #5) Steven, building cc1 to sh-unknown-elf with your patch succeeded. Building sh-rtems4.7 with Steven's patch also succeeds. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19528
[Bug target/19529] [4.0 regression] sh-rtems multilibs broken
--- Additional Comments From corsepiu at gcc dot gnu dot org 2005-01-19 21:31 --- Patch commited. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19529
[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/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/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 URL: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=7948action=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/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
