This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/53833] New: m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
- From: "baker at usgs dot gov" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 02 Jul 2012 23:12:03 +0000
- Subject: [Bug target/53833] New: m68k-uclinux xgcc ICE when compiling libgcc (linux-atomic.c:203:1: in emit_library_call_value_1, at calls.c:4146)
- Auto-submitted: auto-generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
Bug #: 53833
Summary: m68k-uclinux xgcc ICE when compiling libgcc
(linux-atomic.c:203:1: in emit_library_call_value_1,
at calls.c:4146)
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: baker@usgs.gov
Created attachment 27732
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27732
Make m68k-uclinux cross compiler
Host: i686-pc-linux (also x86_64-apple-darwin10.8.0)
Target: m68k-uclinux (Coldfire)
I have been able to create native and cross compilers on CentOS Linux i386 for
gcc 4.6.1 and 4.6.3. However, all attempts to make a cross compiler for gcc
4.7 fail when the new xgcc compiles linux-atomic.c for libgcc (which did not
exist in the gcc 4.6 versions).
I have been compiling the cross compiler with the same version of the native
compiler. Same thing happens when I compile a 4.7 cross compiler with a 4.6
native compiler. (No surprise, because the compiler that fails is the new
xgcc.)
Same result from my Mac OS X 10.6.8 (using a native gcc 4.7.1 compiler I
compiled; 10.6.8 still defaults to a gcc compiler which I used to compile the
native gcc 4.7.1).
Same result using the gcc-4.7-20120630.tar.gz (1 Jul 00:48, 102365191 Bytes)
gcc 4.7 trunk tarball I found at http://fossies.org/unix/misc/. (I saw there
was a slight change in gcc/config/m68k/sync.md; didn't help.)
I suspect the new atomic builtins are no good for a Coldfire processor. But, I
don't know how the cross compiler is being told which flavor of M68000 it is.
The error message (i686-pc-linux to m68k-uclinux) is at:
/usr/local/src/gcc/./gcc/xgcc -B/usr/local/src/gcc/./gcc/
-B/opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/bin/
-B/opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/lib/
-isystem
/opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/include
-isystem
/opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/sys-include
--sysroot=/opt/lantronix/sdk/toolchains/freescale-coldfire-2011.09/m68k-uclinux/libc
-g -O2 -O2 -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 -I. -I. -I../.././gcc
-I../../../gcc-4.7.1/libgcc -I../../../gcc-4.7.1/libgcc/.
-I../../../gcc-4.7.1/libgcc/../gcc -I../../../gcc-4.7.1/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-4.7.1/libgcc/unwind-dw2-fde.c
../../../gcc-4.7.1/libgcc/config/m68k/linux-atomic.c: In function
'__sync_bool_compare_and_swap_1':
../../../gcc-4.7.1/libgcc/config/m68k/linux-atomic.c:203:1: internal compiler
error: in emit_library_call_value_1, at calls.c:4146
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
I have attached the make file I use. (It has a bunch of lines at the bottom
that are disabled from the CodeSourcery shell script I used as a template, from
https://sourcery.mentor.com/GNUToolchain/package9493/public/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux.src.tar.bz2.
They have their own source for their 4.6.1 compiler.
The reason I'm doing this is that all the CodeSourcery cross compilers and the
GNU 4.6.1 and 4.6.3 cross compilers fail with an ICE when I use
-fstack-limit-symbol=_stack_start. I'm trying to figure out if that is fixed
in the 4.7 compilers before I file a bug report.)
Thank you in advance for your assistance.