[Bug other/50925] [4.7/4.8/4.9 Regression][avr] ICE at spill_failure, at reload1.c:2118
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50925 Ralf Corsepius corsepiu at gcc dot gnu.org changed: What|Removed |Added CC||corsepiu at gcc dot gnu.org --- Comment #29 from Ralf Corsepius corsepiu at gcc dot gnu.org --- (In reply to Jorn Wolfgang Rennecke from comment #28) I can't reproduce this with the current trunk. Confirmed. gcc-4.9 doesn't show this bug for --target=avr-rtems4.11, anymore. Can was mark this as known to work for 4.9 ? I am inclined to agree.
[Bug c/57237] Upstreaming the rtems v850 multilib gcc patch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57237 Ralf Corsepius corsepiu at gcc dot gnu.org changed: What|Removed |Added CC||corsepiu at gcc dot gnu.org --- Comment #4 from Ralf Corsepius corsepiu at gcc dot gnu.org --- (In reply to Joel Sherrill from comment #3) Patch committed to 4.7, 4.8, and head. It would have been nice if you'd give the author of a patch a chance to comment, instead of hastily rushing out a patch - Thanks for being more collaborative next time.
[Bug c/50928] m32c ICE building RTEMS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50928
Ralf Corsepius corsepiu at gcc dot gnu.org changed:
What|Removed |Added
CC||corsepiu at gcc dot gnu.org
Known to work||4.7.2
Known to fail||4.8.0
--- Comment #4 from Ralf Corsepius corsepiu at gcc dot gnu.org 2013-03-26
08:30:02 UTC ---
This bug had vanished with gcc-4.7.2, but has returned with gcc-4.8.0:
/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/./gcc/xgcc
-B/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/./gcc/
-nostdinc
-B/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/m32c-rtems4.11/newlib/
-isystem
/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/build/m32c-rtems4.11/newlib/targ-include
-isystem
/builddir/build/BUILD/rtems-4.11-m32c-rtems4.11-gcc-4.8.0/gcc-4.8.0/newlib/libc/include
-B/opt/rtems-4.11/m32c-rtems4.11/bin/ -B/opt/rtems-4.11/m32c-rtems4.11/lib/
-isystem /opt/rtems-4.11/m32c-rtems4.11/include -isystem
/opt/rtems-4.11/m32c-rtems4.11/sys-include-g -O2 -mcpu=m32cm -O2
-I../../../../gcc-4.8.0/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-4.8.0/libgcc
-I../../../../gcc-4.8.0/libgcc/. -I../../../../gcc-4.8.0/libgcc/../gcc
-I../../../../gcc-4.8.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o
_ffsdi2.o -MT _ffsdi2.o -MD -MP -MF _ffsdi2.dep -DL_ffsdi2 -c
../../../../gcc-4.8.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../../../gcc-4.8.0/libgcc/libgcc2.c: In function '__ffssi2':
../../../../gcc-4.8.0/libgcc/libgcc2.c:522:1: error: unable to find a register
to spill in class 'A_REGS'
}
^
../../../../gcc-4.8.0/libgcc/libgcc2.c:522:1: error: this is the insn:
(insn 58 56 59 10 (set (reg:HI 0 r0 [orig:26 D.2817 ] [26])
(zero_extend:HI (mem/u/j:QI (plus:PSI (subreg:PSI (reg:SI 44 [ D.2818
]) 0)
(symbol_ref:PSI (__clz_tab) [flags 0x40] var_decl
0x7f55b9a14ab0 __clz_tab)) [0 __clz_tab S1 A8])))
../../../../gcc-4.8.0/libgcc/libgcc2.c:520 115 {zero_extendqihi2}
(expr_list:REG_DEAD (reg:SI 44 [ D.2818 ])
(nil)))
../../../../gcc-4.8.0/libgcc/libgcc2.c:522: confused by earlier errors, bailing
out
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #9 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-11-05 11:44:22 UTC --- (In reply to comment #8) H have backported similar change to 4.7 branch. Thanks for the backport. Please reopen the PR if there are still problems. Unfortunately, your patch doesn't seem to help much: GCC-4.7's soft-float still seems to be pulling in fp routine from inside of newlib: ... /opt/rtems-4.11/lib/gcc/i386-rtems4.11/4.7.2/../../../../i386-rtems4.11/lib/soft-float/libc.a(lib_a-svfprintf.o): In function `_svfprintf_r': /builddir/build/BUILD/rtems-4.11-i386-rtems4.11-gcc-4.7.2/build/i386-rtems4.11/soft-float/newlib/libc/stdio/../../../../../../gcc-4.7.2/newlib/libc/stdio/vfprintf.c:1072: undefined reference to `__truncxfdf2' /builddir/build/BUILD/rtems-4.11-i386-rtems4.11-gcc-4.7.2/build/i386-rtems4.11/soft-float/newlib/libc/stdio/../../../../../../gcc-4.7.2/newlib/libc/stdio/vfprintf.c:1084: undefined reference to `__ltdf2' /builddir/build/BUILD/rtems-4.11-i386-rtems4.11-gcc-4.7.2/build/i386-rtems4.11/soft-float/newlib/libc/stdio/../../../../../../gcc-4.7.2/newlib/libc/stdio/vfprintf.c:1556: undefined reference to `__eqdf2' /builddir/build/BUILD/rtems-4.11-i386-rtems4.11-gcc-4.7.2/build/i386-rtems4.11/soft-float/newlib/libc/stdio/../../../../../../gcc-4.7.2/newlib/libc/stdio/vfprintf.c:1603: undefined reference to `__nedf2'
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #12 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-11-05 12:41:56 UTC --- (In reply to comment #11) You should use t-softfp instead of 386/t-softfp for i[34567]86-*-rtems* in libgcc/config.host. In fact, there should be no i386/t-softfp for any x86 target. You mean, we should apply a patch similar to this? --- a/libgcc/config.host +++ b/libgcc/config.host @@ -568,7 +568,7 @@ i[34567]86-*-nto-qnx*) extra_parts=crtbegin.o ;; i[34567]86-*-rtems*) - tmake_file=$tmake_file i386/t-softfp i386/t-crtstuff + tmake_file=$tmake_file i386/t-crtstuff extra_parts=$extra_parts crti.o crtn.o ;; i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*) @@ -1165,6 +1165,7 @@ i[34567]86-*-darwin* | x86_64-*-darwin* | \ i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \ i[34567]86-*-linux* | x86_64-*-linux* | \ i[34567]86-*-gnu* | \ + i[34567]86-*-rtems* | \ i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]* | \ i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw* | \ i[34567]86-*-freebsd* | x86_64-*-freebsd*) The breakdown above is with this patch applied.
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #15 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-11-05 14:38:44 UTC --- (In reply to comment #14) (In reply to comment #13) Then the problem is either in newlib or generic libgcc configury. I meanwhile came to the latter conclusion. The math calls are being pulled-in by gcc's code generation from inside of newlib's libm, but soft-fp emulation is missing in libgcc. As we have both hard and soft-float multilib variants, I think RTEMS needs a softfp wrapper. Please note that t-fdpbit is not enabled by default for x86 anymore. I don't know if this was intentional omission during libgcc conversion, but nobody missed it until today. OK, will check. The second part of your patch enables TFmode soft-float, probably not needed for RTEMS. I think that you need either t-fdpbit or t-softfp-sfdf added to i[34567]86-*-rtems*) Thanks for these hints - I am currently investigating, but ... things like these take _a lot of time_.
[Bug bootstrap/52466] gcc-4.7.0-RC-20120302 fails to build for --target=lm32-rtems4.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466 --- Comment #7 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-11-05 15:17:21 UTC --- (In reply to comment #6) Created attachment 28618 [details] For sjlj exceptions on for lm32*-*-* Is this the correct way to force it on? AFAICT, yes. I don't see any other place to do this and the build gets through this issue with this patch. Not for me w/ gcc-4_7-branch: /users/rtems/src/rtems.org/rtems-gcc/BUILD-lm32/./gcc/xgcc -B/users/rtems/src/rtems.org/rtems-gcc/BUILD-lm32/./gcc/ -nostdinc -B/users/rtems/src/rtems.org/rtems-gcc/BUILD-lm32/lm32-rtems4.11/newlib/ -isystem /users/rtems/src/rtems.org/rtems-gcc/BUILD-lm32/lm32-rtems4.11/newlib/targ-include -isystem /users/rtems/src/rtems.org/rtems-gcc/newlib/libc/include -B/opt/rtems-4.11/lm32-rtems4.11/bin/ -B/opt/rtems-4.11/lm32-rtems4.11/lib/ -isystem /opt/rtems-4.11/lm32-rtems4.11/include -isystem /opt/rtems-4.11/lm32-rtems4.11/sys-include-g -O2 -Wall -mmultiply-enabled -O2 -I../../../../libgcc/../newlib/libc/sys/rtems/include -g -O2 -Wall -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -G 0 -msign-extend-enabled -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -G 0 -msign-extend-enabled -I. -I. -I../../.././gcc -I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc -I../../../../libgcc/../include-o _ffssi2.o -MT _ffssi2.o -MD -MP -MF _ffssi2.dep -DL_ffssi2 -c ../../../../libgcc/libgcc2.c xgcc: internal compiler error: Segmentation fault (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [_ffssi2.o] Error 4 make[4]: Leaving directory `/users/rtems/src/rtems.org/rtems-gcc/BUILD-lm32/lm32-rtems4.11/mmultiply-enabled/libgcc'
[Bug target/55175] i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175 --- Comment #6 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-11-03 06:25:33 UTC --- I can confirm i386-rtems4.11-gcc now builds. @Uros: I am inclined to believe this patch probably should be backported to 4.7.x. At least, RTEMS is facing bizarre compilation issues, which I would not want to be related to similar issues as this.
[Bug bootstrap/55175] New: i386/sfp-exceptions.c:52:7: error: impossible constraint in 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55175
Bug #: 55175
Summary: i386/sfp-exceptions.c:52:7: error: impossible
constraint in 'asm'
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: corse...@gcc.gnu.org
Created attachment 28594
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28594
*.i of the file raising the breakdown
Bootstrapping gcc-trunk (xgcc (GCC) 4.8.0 20120927 (experimental)) fails with
this error for --target=i386-rtems4.11:
...
/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/./gcc/xgcc
-B/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/./gcc/ -nostdinc
-B/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/i386-rtems4.11/soft-float/newlib/
-isystem
/users/rtems/src/rtems.org/rtems-gcc/BUILD-i386/i386-rtems4.11/soft-float/newlib/targ-include
-isystem /users/rtems/src/rtems.org/rtems-gcc/newlib/libc/include
-B/opt/rtems-4.11/i386-rtems4.11/bin/ -B/opt/rtems-4.11/i386-rtems4.11/lib/
-isystem /opt/rtems-4.11/i386-rtems4.11/include -isystem
/opt/rtems-4.11/i386-rtems4.11/sys-include -msoft-float -g -O2 -Wall -O2
-I../../../../libgcc/../newlib/libc/sys/rtems/include -g -O2 -Wall -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector
-Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../libgcc
-I../../../../libgcc/. -I../../../../libgcc/../gcc
-I../../../../libgcc/../include -DHAVE_CC_TLS -o sfp-exceptions.o -MT
sfp-exceptions.o -MD -MP -MF sfp-exceptions.dep -c
../../../../libgcc/config/i386/sfp-exceptions.c -fvisibility=hidden
-DHIDE_EXPORTS
../../../../libgcc/config/i386/sfp-exceptions.c: In function
'__sfp_handle_exceptions':
../../../../libgcc/config/i386/sfp-exceptions.c:52:7: error: impossible
constraint in 'asm'
asm volatile (fdiv\t{%y0, %0|%0, %y0} : +t (f));
^
../../../../libgcc/config/i386/sfp-exceptions.c:62:7: error: impossible
constraint in 'asm'
asm volatile (fdivs\t%1 : +t (f) : m (g));
^
make: *** [sfp-exceptions.o] Error 1
[Bug bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231 --- Comment #3 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-11-02 05:35:18 UTC --- DJ, any chances to see your patch from comment#1 be commited?
[Bug other/51417] Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417 --- Comment #6 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-03-07 10:59:59 UTC --- Author: corsepiu Date: Wed Mar 7 10:59:56 2012 New Revision: 185034 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185034 Log: 2012-03-05 Ralf Corsépius ralf.corsep...@rtems.org PR target/51417 * Makefile.in: Let install-gcc-ar depend on installdirs, gcc-ar$(exeext), gcc-nm$(exeext), gcc-ranlib$(exeext). Don't double canonicalize if cross-compiling. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/Makefile.in
[Bug other/51417] Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417 --- Comment #7 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-03-07 11:39:29 UTC --- Author: corsepiu Date: Wed Mar 7 11:39:25 2012 New Revision: 185035 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=185035 Log: 2012-03-05 Ralf Corsépius ralf.corsep...@rtems.org PR target/51417 * Makefile.in: Let install-gcc-ar depend on installdirs, gcc-ar$(exeext), gcc-nm$(exeext), gcc-ranlib$(exeext). Don't double canonicalize if cross-compiling. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in
[Bug other/51417] Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417
--- Comment #3 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-03-05
15:12:39 UTC ---
Created attachment 26835
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26835
Fix installation of gcc-{ar,nm,ranlib)
The approach this patch is based on, is copied from gcc/lang/Make-lang.in
(eg. gcc/go/Make-lang.in) (Use gcc-cross as indicator).
[Bug other/51417] Cross-compiler - wrappers for ar, nm, ranlib installed under wrong names
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51417 Ralf Corsepius corsepiu at gcc dot gnu.org changed: What|Removed |Added CC||corsepiu at gcc dot gnu.org --- Comment #5 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-03-05 15:58:04 UTC --- (In reply to comment #4) Please post the patch to gcc-patches and say how you tested it. I'll ack it for the 4.7 branch then. Done. FTR: I am testing by building various linux-rtems cross toolchains and Canadian cross-building mingw32-rtems and cygwin-rtems toolchains on Linux.
[Bug bootstrap/52466] gcc-4.7.0-RC-20120302 fails to build for --target=lm32-rtems4.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52466
Ralf Corsepius corsepiu at gcc dot gnu.org changed:
What|Removed |Added
Target||lm32-*
CC||corsepiu at gcc dot gnu.org
Known to work||4.5.3
Known to fail||4.6.3, 4.7.0
--- Comment #1 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-03-06
07:20:31 UTC ---
Upon second glance, the origin of this bootstrap failure is an ICE in xgcc/cc1
as lm32-rtems4.11/libgcc/config.log tells
configure:4511: checking whether to use setjmp/longjmp exceptions
configure:: /users/rtems/tmp/gcc.2/BUILD-lm32/./gcc/xgcc
-B/users/rtems/tmp/gcc.2/BUILD-lm32/./gcc/ -B/usr/local/lm32-rtems4.11/bin/
-B/usr/local/lm32-rtems4.11/lib/ -isystem /usr/local/lm32-rtems4.11/include
-isystem /usr/local/lm32-rtems4.11/sys-include
-c --save-temps -fexceptions conftest.c 5
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
configure:: $? = 4
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgcc/;
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define SIZEOF_DOUBLE 0
| #define SIZEOF_LONG_DOUBLE 0
| #define HAVE_GETIPINFO 1
| /* end confdefs.h. */
|
| void bar ();
| void clean (int *);
| void foo ()
| {
| int i __attribute__ ((cleanup (clean)));
| bar();
| }
|
configure:4542: result: unknown
configure:4558: error: unable to detect exception model
[Bug bootstrap/17601] gcc/Makefile.in: Setting up XX_FOR_TARGET does not work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17601 Ralf Corsepius corsepiu at gcc dot gnu.org changed: What|Removed |Added CC||corsepiu at gcc dot gnu.org --- Comment #8 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-01-11 14:03:55 UTC --- (In reply to comment #7) Is this still an issue? This BZ is such kind old, I would not have remembered it ;) Anyway, I've built RTEMS toolchains many hundred times since then without any patch related to this issue applied. So my guess is this BZ has magically been healed, now is obsolete and can be closed.
[Bug bootstrap/48231] bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231 --- Comment #2 from Ralf Corsepius corsepiu at gcc dot gnu.org 2012-01-10 07:55:14 UTC --- (In reply to comment #1) See if this helps: You made my day - Your patch lets building gcc-4.6.2 for --target=h8300-rtems* succeed (using binutils-2.22).
[Bug go/48407] libgo/configure --without-libffi doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48407 --- Comment #4 from Ralf Corsepius corsepiu at gcc dot gnu.org 2011-04-04 11:40:59 UTC --- (In reply to comment #3) I have this in my local tree. I recall Ian and I discussing that since Go and GCJ both need libffi, the logic should be smarter. Joel, as you may have gueess, I also have a similar patch as the one you posted here applied, because otherwise nothing builds, however this is a different issue. So, let me try to refine my issues: * libgo/configure's --without-libffi, suggests GCC (rsp. libgo) could be built without libffi. This apparently does not apply. libgo (currently) strictly requires libffi. In other words, --without-libffi doesn't do what a user who is not deeply intimate with libgo, may think it does. libgo/configure's --without-libffi actually is closer to --with/without-external-libffi than to --with/without-libffi. That said, may-be renaming it could be considered. * GCC's toplevel configure doesn't honor --with/without-libffi (neither in the sense of external-ffi nor in the sense of not using libffi).
[Bug go/48410] New: weird installation dir
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48410
Summary: weird installation dir
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: corse...@gcc.gnu.org
When cross-building gccgo (gcc-4.6.0) for *-rtems* targets,
libgo's *.gox files end up installed under a what I assume to be a bogus
directory:
e.g.:
/opt/rtems-4.11/lib/gcc/i386-rtems4.11/4.6.0/mpentium/go/4.6.0/i386-rtems4.11/archive/tar.gox
${prefix}/lib/gcc/${target}/${gcc_version}/${multisubdir}/go/${gcc_version}/${target}/...
At least I would expect them to end up under
${prefix}/lib/gcc/${target}/${gcc_version}/${multisubdir}/go
(This would match how other languages support targets files are installed,
e.g. libstdc++)
FYI: I am configuring gcc with --enable-version-specific-runtime-libs
I would not want to exclude this issue to be related to this option,
because other languages had similar issues related to this option in the past.
[Bug go/48411] New: Bogusly canonicalized $target-gccgo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48411 Summary: Bogusly canonicalized $target-gccgo Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: corse...@gcc.gnu.org Crossbuilding gcc with go enable installs the target's gccgo under a bogusly canonizalized name: E.g. (--prefix=/opt/rtems4.11 --target=i386-rtems4.11 ...) results in: /opt/rtems-4.11/bin/i386-rtems4.11-i386-rtems4.11-gccgo Correct would be: /opt/rtems-4.11/bin/i386-rtems4.11-gccgo
[Bug go/48407] New: libgo/configure --without-libffi doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48407 Summary: libgo/configure --without-libffi doesn't work Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: corse...@gcc.gnu.org libgo/configure.ac supplies --without-libffi However, libgo/runtime/go-reflect-call.c unconditionally includes ffi.h. I.e. this option doen't do what libgo/configure --help ... --without-libffidon't use libffi ... suggests.
[Bug go/48408] New: libgo/configure should be excecutable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48408 Summary: libgo/configure should be excecutable Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: go AssignedTo: i...@airs.com ReportedBy: corse...@gcc.gnu.org Minor issue with libgo in GCC's svn: The file libgo/configure in svn should be excecutable.
[Bug bootstrap/48230] New: bootstrapping gcc-4.6.0-RC-20110321 fails for lm32-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48230 Summary: bootstrapping gcc-4.6.0-RC-20110321 fails for lm32-rtems* Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: corse...@gcc.gnu.org bootstrapping gcc-4.6.0-RC-20110321 fails for --target=lm32-rtems* fails with an ICE: ... /builddir/build/BUILD/rtems-4.11-lm32-rtems4.11-gcc-4.6.0/build/./gcc/xgcc -B/builddir/build/BUILD/rtems-4.11-lm32-rtems4.11-gcc-4.6.0/build/./gcc/ -nostdinc -B/builddir/build/BUILD/rtems-4.11-lm32-rtems4.11-gcc-4.6.0/build/lm32-rtems4.11/newlib/ -isystem /builddir/build/BUILD/rtems-4.11-lm32-rtems4.11-gcc-4.6.0/build/lm32-rtems4.11/newlib/targ-include -isystem /builddir/build/BUILD/rtems-4.11-lm32-rtems4.11-gcc-4.6.0/gcc-4.6.0-RC-20110321/newlib/libc/include -B/opt/rtems-4.11/lm32-rtems4.11/bin/ -B/opt/rtems-4.11/lm32-rtems4.11/lib/ -isystem /opt/rtems-4.11/lm32-rtems4.11/include -isystem /opt/rtems-4.11/lm32-rtems4.11/sys-include-g -O2 -mbarrel-shift-enabled -O2 -I../../gcc-4.6.0-RC-20110321/gcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -Dinhibit_libc -G 0 -msign-extend-enabled -I. -I. -I../../.././gcc -I../../../../gcc-4.6.0-RC-20110321/libgcc -I../../../../gcc-4.6.0-RC-20110321/libgcc/. -I../../../../gcc-4.6.0-RC-20110321/libgcc/../gcc -I../../../../gcc-4.6.0-RC-20110321/libgcc/../include-o _ffsdi2.o -MT _ffsdi2.o -MD -MP -MF _ffsdi2.dep -DL_ffsdi2 -c ../../../../gcc-4.6.0-RC-20110321/libgcc/../gcc/libgcc2.c \ xgcc: internal compiler error: Segmentation fault (program cc1) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [_ffssi2.o] Error 4 This is a regression against gcc-4.5.2, which bootstrapped flawlessly
[Bug bootstrap/48231] New: bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48231 Summary: bootstrapping gcc-4.6.0-RC-20110321 fails for h8300-rtems* Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: corse...@gcc.gnu.org bootstrapping gcc-4.6.0-RC-20110321 fails for --target=h8300-rtems* with a segfault in as (binutils-2.21): ... /bin/sh ../libtool --tag CXX --mode=compile /builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/./gcc/xgcc -shared-libgcc -B/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/./gcc -nostdinc++ -L/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/libstdc++-v3/src -L/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/libstdc++-v3/src/.libs -nostdinc -B/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/newlib/ -isystem /builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/newlib/targ-include -isystem /builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/gcc-4.6.0-RC-20110321/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 -I/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/libstdc++-v3/include/h8300-rtems4.11 -I/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/libstdc++-v3/include -I/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/gcc-4.6.0-RC-20110321/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c -o locale-inst.lo ../../../../gcc-4.6.0-RC-20110321/libstdc++-v3/src/locale-inst.cc libtool: compile: /builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/./gcc/xgcc -shared-libgcc -B/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/./gcc -nostdinc++ -L/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/libstdc++-v3/src -L/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/libstdc++-v3/src/.libs -nostdinc -B/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/newlib/ -isystem /builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/newlib/targ-include -isystem /builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/gcc-4.6.0-RC-20110321/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 -I/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/libstdc++-v3/include/h8300-rtems4.11 -I/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/build/h8300-rtems4.11/libstdc++-v3/include -I/builddir/build/BUILD/rtems-4.11-h8300-rtems4.11-gcc-4.6.0/gcc-4.6.0-RC-20110321/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c ../../../../gcc-4.6.0-RC-20110321/libstdc++-v3/src/locale-inst.cc -o locale-inst.o /tmp/ccuoymTp.s: Assembler messages: /tmp/ccuoymTp.s:69895: Error: value of 66089 too large for field of 2 bytes at 15035 /tmp/ccuoymTp.s:70073: Error: value of 66488 too large for field of 2 bytes at 15309 /tmp/ccuoymTp.s:70201: Error: value of 66846 too large for field of 2 bytes at 15508 /opt/rtems-4.11/h8300-rtems4.11/bin/as: BFD (GNU Binutils) 2.21 assertion fail ../../binutils-2.21/bfd/elf.c:2795 xgcc: internal compiler error: Segmentation fault (program as) Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [istream-inst.lo] Error 1 This is a regression against gcc-4.5.2, which built flawlessly
[Bug target/37665] invalid loop generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37665 Ralf Corsepius corsepiu at gcc dot gnu.org changed: What|Removed |Added CC||corsepiu at gcc dot gnu.org --- Comment #2 from Ralf Corsepius corsepiu at gcc dot gnu.org 2011-01-27 14:02:45 UTC --- Joel, could you check if this bug still is present and if it affects RTEMS? From what I can gather from looking at the asm gcc generates, this bug might be fixed in gcc-4.5.x (rtems-4.11)
[Bug target/46692] Missing LM32 multilibs for divider and sign extender
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46692 Ralf Corsepius corsepiu at gcc dot gnu.org changed: What|Removed |Added CC||corsepiu at gcc dot ||gnu.org, joel at oarcorp ||dot com --- Comment #1 from Ralf Corsepius corsepiu at gcc dot gnu.org 2010-11-28 14:27:13 UTC --- Would you mind to explain, why you need this, rsp. why the current default multilibs do not suffice your needs? Adding a multilibs to the default set of multilibs needs of a target needs to be very well motivated and can not be done light-heartedly. Knowing you actually are working with lm32-rtems and not with lm32-* targets, provided you can sufficiently motivate this change, raises the question if it would not actally be more appropriate to extend the lm32-rtems multilib set instead of the general set of multilibs.
[Bug target/46372] New: format '%f' expects type 'double', but argument 3 has type 'float'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46372
Summary: format '%f' expects type 'double', but argument 3 has
type 'float'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: corse...@gcc.gnu.org
I am facing the warning from the subject when compiling this snippet below with
avr-*gcc's:
-- snip --
#include stdio.h
int main()
{
float f = 2.0;
fprintf( stdout, %f\n, f );
}
-- snip --
# avr-rtems4.10-gcc -O2 -o foo -c foo.c -Wall
foo.c: In function 'main':
foo.c:6: warning: format '%f' expects type 'double', but argument 3 has type
'float'
# avr-rtems4.10-gcc --version
avr-rtems4.10-gcc (GCC) 4.4.5 20101001 (RTEMS
gcc-4.4.5-2.fc13/newlib-1.18.0-17.fc13)
# avr-gcc -O2 -o foo -c foo.c -Wall
foo.c: In function 'main':
foo.c:6:3: warning: format '%f' expects type 'double', but argument 3 has type
'float'
# avr-gcc --version
avr-gcc (Fedora 4.5.1-2.fc13) 4.5.1
