[Bug target/16350] gcc only understands little endian ARM systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350 --- Comment #28 from Marc Kleine-Budde mkl at pengutronix dot de 2012-02-13 23:23:56 UTC --- (In reply to comment #27) The precise scope of this bug is unclear to me. It's linux specific. Big endian Linux targets _do_ seem to work now, and -mbig-endian generates correct code regardless; however, non-Linux big-endian targets do not seem to be recognized as big-endian by default (which means libgcc is built in little endian mode, etc.). See bug 52187 (which may be a dupe of this one, depending on how you interpret the scope of this bug). As Richard sid (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52187#c3) you can activate multilib on non-linux target and have both big and little endian libgcc. regards, Marc
[Bug target/16350] gcc only understands little endian ARM systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350 --- Comment #29 from Marc Kleine-Budde mkl at pengutronix dot de 2012-02-13 23:24:28 UTC --- (In reply to comment #27) The precise scope of this bug is unclear to me. It's linux specific. Big endian Linux targets _do_ seem to work now, and -mbig-endian generates correct code regardless; however, non-Linux big-endian targets do not seem to be recognized as big-endian by default (which means libgcc is built in little endian mode, etc.). See bug 52187 (which may be a dupe of this one, depending on how you interpret the scope of this bug). As Richard said (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52187#c3) you can activate multilib on non-linux target and have both big and little endian libgcc. regards, Marc
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
--- Comment #3 from mkl at pengutronix dot de 2009-05-29 08:22 --- Hello Andrew, (In reply to comment #2) http://www.nabble.com/Re:-libFFI-arm-compilation-fails-with-assembly-td20346235.html BTW: I'm not compiling libffi stand alone, here. I'm building the gcc with java enabled. IMHO using -mfloat-abi=soft when preprocessing sysv.S can be considered a workaround not a fix. It makes only sense if the compiler passes (by default) floats in the integer registers (-mfloat-abi=soft and -mfloat-abi=softfp), and breaks if passing in the float registers (-mfloat-abi=hard). With the work done in ARM/hardvfp_4_4_branch the -mfloat-abi=hard case is more relevant then ever. This means we cannot use -mfloat-abi=soft unconditionally, which boils down (again) to the question: how can we distinguish between the float-passed-in-int-regs and float-passed-in-float-regs case. Ideally this should work if building libffi as part of gcc and if building libffi standalone. cheers, Marc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug libffi/40242] New: unsupported asm instructions in libffi/src/arm/sysv.S
Hello, during cross compilation of gcc, the libffi build for the target breaks with this error message: libtool: compile: /home/frogger/pengutronix/toolchain/libffi/build/./gcc/xgcc -B/home/frogger/pengutronix/toolchain/libffi/build/./gcc/ -B/usr/local/arm-1136jfs-linux-gnueabi/bin/ -B/usr/local/arm-1136jfs-linux-gnueabi/lib/ -isystem /usr/local/arm-1136jfs-linux-gnueabi/include -isystem /usr/local/arm-1136jfs-linux-gnueabi/sys-include -I. -I../../../gcc-4.4.0/libffi/include -Iinclude -I../../../gcc-4.4.0/libffi/src -g -O2 -c ../../../gcc-4.4.0/libffi/src/arm/sysv.S -fPIC -DPIC -o src/arm/.libs/sysv.o ../../../gcc-4.4.0/libffi/src/arm/sysv.S: Assembler messages: ../../../gcc-4.4.0/libffi/src/arm/sysv.S:202: Error: selected processor does not support `stfeqs f0,[r2]' ../../../gcc-4.4.0/libffi/src/arm/sysv.S:207: Error: selected processor does not support `stfeqd f0,[r2]' ../../../gcc-4.4.0/libffi/src/arm/sysv.S:282: Error: selected processor does not support `ldfs f0,[sp]' ../../../gcc-4.4.0/libffi/src/arm/sysv.S:285: Error: selected processor does not support `ldfd f0,[sp]' ../../../gcc-4.4.0/libffi/src/arm/sysv.S:288: Error: selected processor does not support `ldfd f0,[sp]' the offending code is: #ifndef __SOFTFP__ beq LSYM(Lepilogue) @ return FLOAT cmp r3, #FFI_TYPE_FLOAT stfeqs f0, [r2] beq LSYM(Lepilogue) @ return DOUBLE or LONGDOUBLE cmp r3, #FFI_TYPE_DOUBLE stfeqd f0, [r2] #endif gcc is configured this way: ../gcc-4.4.0/configure --enable-languages=c,c++,java --target=arm-1136jfs-linux-gnueabi --with-mpfr=/home/frogger/pengutronix/toolchain/OSELAS.Toolchain-trunk/platform-arm-v4t-linux-gnueabi-gcc-4.4.0-glibc-2.9-binutils-2.19.1-kernel-2.6.29-sanitized/sysroot-host --with-gmp=/home/frogger/pengutronix/toolchain/OSELAS.Toolchain-trunk/platform-arm-v4t-linux-gnueabi-gcc-4.4.0-glibc-2.9-binutils-2.19.1-kernel-2.6.29-sanitized/sysroot-host --with-float=softfp --with-fpu=vfp --with-cpu=arm1136jf-s --with-sysroot=/opt/OSELAS.Toolchain-1.99.3/arm-1136jfs-linux-gnueabi/gcc-4.3.2-glibc-2.8-binutils-2.19-kernel-2.6.27-sanitized/sysroot-arm-1136jfs-linux-gnueabi I.e. as an arm-eabi target, --with-fpu=vfp and --with-float=softfp. Which means floats are passed in integer registers, but in function the compiler generates floating point instructions, the preprocessor doesn't define a __SOFTFP__ symbol. If configuring the compiler with --with-float=soft it will pass floats in integer registers and it will generate softfloat emulation code. In this case the preprocessor defines __SOFTFP__. In both variants the function calling convention is the same, but in one case we have the __SOFTFP__ symbol in the other not. libffi changes it's behaviour depending on this symbol, which is IMHO not correct. I've tested some combinations, this is the summary of (echo | arm-v4t-linux-gnueabi-cpp -dM -mfloat-abi=XXX -mfpu=YYY| egrep -i 'vfp|fp|soft|hard|float'): -mfloat-abi=soft -mfpu=vfp__SOFTFP__ __VFP_FP__ -mfloat-abi=softfp -mfpu=vfp __VFP_FP__ -mfloat-abi=hard -mfpu=vfp __VFP_FP__ (sorry, unimplemented) -mfloat-abi=soft -mfpu=fpa__SOFTFP__ -mfloat-abi=softfp -mfpu=fpa -mfloat-abi=hard -mfpu=fpa I'm not sure which of these combinations makes sense, or are actually used, the 3rd one seems not to be implemented, though. We at pengutronix use usually 1. and 2. In some weird projects 4. and 6. but not with the current gcc. This table shows that it's not possible to distinguish between the hard and softfp case, a diff off the preprocessor's output shows no difference in the symbols tough. On the upside the vfp-hard case seems not to be implemented. So the question is which is the correct symbol for libffi? cheers, Marc -- Summary: unsupported asm instructions in libffi/src/arm/sysv.S Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libffi AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mkl at pengutronix dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: arm-1136jfs-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug target/37220] internal compiler error: Segmentation fault during cross compilation
--- Comment #5 from mkl at pengutronix dot de 2008-08-27 20:11 --- Hi Joseph, I just backported the fix from gcc-4.4 to 4.3.2-RC. The patch fixes the problem, any change to get that into 4.3.2? cheers, Marc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37220
[Bug target/37220] internal compiler error: Segmentation fault during cross compilation
--- Comment #2 from mkl at pengutronix dot de 2008-08-25 13:26 --- Fails too with the gcc-4.3.2-RC [EMAIL PROTECTED]:~/pengutronix/toolchain/procps]$ /opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.2-RC-20080819-glibc-2.8-kernel-2.6.26-sanitized/bin/ arm-v4t-linux-gnueabi-gcc test.i -o test.o -c -O2 -frename-registers -v Using built-in specs. Target: arm-v4t-linux-gnueabi Configured with: /home/mkl/pengutronix/toolchain/OSELAS.Toolchain-trunk/build-cross/gcc-4.3.2-RC-20080819/configure --target=arm-v4t-linux-gnueabi --with-arch=armv4t --with-float=soft --with-fpu=vfp --enable-__cxa_atexit --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion=OSELAS.Toolchain-trunk [EMAIL PROTECTED] --with-gmp=/home/mkl/pengutronix/toolchain/OSELAS.Toolchain-trunk/sysroot-host --with-mpfr=/home/mkl/pengutronix/toolchain/OSELAS.Toolchain-trunk/sysroot-host --disable-multilib --with-sysroot=/opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.2-RC-20080819-glibc-2.8-kernel-2.6.26-sanitized/sysroot-arm-v4t-linux-gnueabi --prefix=/opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.2-RC-20080819-glibc-2.8-kernel-2.6.26-sanitized --enable-languages=c,c++ --enable-threads=posix --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --enable-checking=release --enable-shared Thread model: posix gcc version 4.3.2 20080819 (prerelease) (OSELAS.Toolchain-trunk) COLLECT_GCC_OPTIONS='-o' 'test.o' '-c' '-O2' '-frename-registers' '-v' '-march=armv4t' '-mfloat-abi=soft' '-mfpu=vfp' /opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.2-RC-20080819-glibc-2.8-kernel-2.6.26-sanitized/libexec/gcc/arm-v4t-linux-gnueabi/4.3.2/cc1 -fpreprocessed test.i -quiet -dumpbase test.i -march=armv4t -mfloat-abi=soft -mfpu=vfp -auxbase-strip test.o -O2 -version -frename-registers -o /tmp/ccmLNDgC.s GNU C (OSELAS.Toolchain-trunk) version 4.3.2 20080819 (prerelease) (arm-v4t-linux-gnueabi) compiled by GNU C version 4.2.3 (Debian 4.2.3-5), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: c833c2259e4aaa3c1e123fcca3f6dea0 test.i: In function 'get_pid_digits': test.i:27: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37220
[Bug target/37220] internal compiler error: Segmentation fault during cross compilation
--- Comment #3 from mkl at pengutronix dot de 2008-08-25 13:32 --- works with 4.4-20080822, though cheers Marc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37220
[Bug c/37220] New: internal compiler error: Segmentation fault during cross compilation
-fixed /opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.1-glibc-2.8-kernel-2.6.26-sanitized/lib/gcc/arm-v4t-linux-gnueabi/4.3.1/../../../../arm-v4t-linux-gnueabi/include /opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.1-glibc-2.8-kernel-2.6.26-sanitized/sysroot-arm-v4t-linux-gnueabi/usr/include End of search list. GNU C (OSELAS.Toolchain-trunk) version 4.3.1 (arm-v4t-linux-gnueabi) compiled by GNU C version 4.2.3 (Debian 4.2.3-5), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 85c0010da2dd76e8224d87b88d7316fe proc/sysinfo.c: In function 'get_pid_digits': proc/sysinfo.c:896: internal compiler error: Segmentation fault The attached minial testcase: It boils down to -O2 -frename-registers: arm-v4t-linux-gnueabi-gcc test.i -o test.o -c -O2 -frename-registers -v Using built-in specs. Target: arm-v4t-linux-gnueabi Configured with: /home/mkl/pengutronix/toolchain/OSELAS.Toolchain-trunk/build-cross/gcc-4.3.1/configure --target=arm-v4t-linux-gnueabi --with-arch=armv4t --with-float=soft --with-fpu=vfp --enable-__cxa_atexit --disable-nls --disable-decimal-float --disable-fixed-point --disable-win32-registry --enable-symvers=gnu --with-pkgversion=OSELAS.Toolchain-trunk [EMAIL PROTECTED] --with-gmp=/home/mkl/pengutronix/toolchain/OSELAS.Toolchain-trunk/sysroot-host --with-mpfr=/home/mkl/pengutronix/toolchain/OSELAS.Toolchain-trunk/sysroot-host --disable-multilib --with-sysroot=/opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.1-glibc-2.8-kernel-2.6.26-sanitized/sysroot-arm-v4t-linux-gnueabi --prefix=/opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.1-glibc-2.8-kernel-2.6.26-sanitized --enable-languages=c,c++ --enable-threads=posix --enable-c99 --enable-long-long --enable-libstdcxx-debug --enable-profile --enable-checking=release --enable-shared Thread model: posix gcc version 4.3.1 (OSELAS.Toolchain-trunk) COLLECT_GCC_OPTIONS='-o' 'test.o' '-c' '-O2' '-frename-registers' '-v' '-march=armv4t' '-mfloat-abi=soft' '-mfpu=vfp' /opt/OSELAS.Toolchain-trunk/arm-v4t-linux-gnueabi/gcc-4.3.1-glibc-2.8-kernel-2.6.26-sanitized/libexec/gcc/arm-v4t-linux-gnueabi/4.3.1/cc1 -fpreprocessed test.i -quiet -dumpbase test.i -march=armv4t -mfloat-abi=soft -mfpu=vfp -auxbase-strip test.o -O2 -version -frename-registers -o /tmp/ccKA7wKV.s GNU C (OSELAS.Toolchain-trunk) version 4.3.1 (arm-v4t-linux-gnueabi) compiled by GNU C version 4.2.3 (Debian 4.2.3-5), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 85c0010da2dd76e8224d87b88d7316fe test.i: In function 'get_pid_digits': test.i:27: internal compiler error: Segmentation fault cheers, Marc -- Summary: internal compiler error: Segmentation fault during cross compilation Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mkl at pengutronix dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: arm-v4t-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37220
[Bug c/37220] internal compiler error: Segmentation fault during cross compilation
--- Comment #1 from mkl at pengutronix dot de 2008-08-24 12:49 --- Created an attachment (id=16136) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16136action=view) minimal test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37220
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #13 from mkl at pengutronix dot de 2006-11-29 09:55 --- Created an attachment (id=12705) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12705action=view) fix target linker emulation for arm elf and eabi (take 3) If you try to build a big-endian eabi toolchain, you need another fix (see patch of gcc/config/arm/linux-eabi.h) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #12 from mkl at pengutronix dot de 2006-11-03 13:49 --- Created an attachment (id=12542) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12542action=view) fix target linker emulation for arm elf and eabi (take 2) If you try to build a big-endian eabi toolchain, you need another fix (see patch of gcc/config/arm/linux-eabi.h) -- mkl at pengutronix dot de changed: What|Removed |Added Attachment #12042|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug c/28675] New: ICE in extract_insn, at recog.c:2084 (nrecognizable insn) [arm]
We get the following ICE when crosscompiling fbtest from i686-pc-linux-gnu to arm-ep93xx-linux-gnueabi. -O3 breaks, -O2 works [EMAIL PROTECTED]:~/pengutronix/ptxdist/bug]$ arm-ep93xx-linux-gnueabi-gcc -c -Wall -O3 -fomit-frame-pointer -o minimal.o minimal.c -save-temps -v Using built-in specs. Target: arm-ep93xx-linux-gnueabi Configured with: /home/mkl/pengutronix/ptxdist/build/toolchain-arm-ep93xx-linux-gnueabi/build-cross/gcc-4.1.1/configure --host=i686-host-linux-gnu --target=arm-ep93xx-linux-gnueabi --prefix=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4 --with-local-prefix=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi --with-sysroot=/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi --disable-multilib --disable-nls --enable-symvers=gnu --enable-__cxa_atexit --enable-c99 --enable-long-long --enable-shared --enable-threads=posix --enable-languages=c,c++ Thread model: posix gcc version 4.1.1 /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/libexec/gcc/arm-ep93xx-linux-gnueabi/4.1.1/cc1 -E -quiet -v minimal.c -Wall -fomit-frame-pointer -O3 -fpch-preprocess -o minimal.i ignoring nonexistent directory /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/include #include ... search starts here: #include ... search starts here: /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/lib/gcc/arm-ep93xx-linux-gnueabi/4.1.1/include /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/lib/gcc/arm-ep93xx-linux-gnueabi/4.1.1/../../../../arm-ep93xx-linux-gnueabi/include /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/sysroot-arm-ep93xx-linux-gnueabi/usr/include End of search list. /opt/ptxdist-0.10.svn/arm-ep93xx-linux-gnueabi/gcc-4.1.1-glibc-2.4/libexec/gcc/arm-ep93xx-linux-gnueabi/4.1.1/cc1 -fpreprocessed minimal.i -quiet -dumpbase minimal.c -auxbase-strip minimal.o -O3 -Wall -version -fomit-frame-pointer -o minimal.s GNU C version 4.1.1 (arm-ep93xx-linux-gnueabi) compiled by GNU C version 4.1.2 20060729 (prerelease) (Debian 4.1.1-10). GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 770ce336670905d74fe72d7a025d3915 minimal.c: In function 'main': minimal.c:49: error: unrecognizable insn: (insn 284 119 282 13 (set (reg:HI 14 lr) (mem/s:HI (plus:SI (mult:SI (reg/v:SI 1 r1 [orig:122 i ] [122]) (const_int 16 [0x10])) (reg:SI 6 r6 [orig:114 clut.1 ] [114])) [3 variable.r+0 S4 A32])) -1 (nil) (nil)) minimal.c:49: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE in extract_insn, at recog.c:2084 (nrecognizable insn) [arm] Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mkl at pengutronix dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: arm-ep93xx-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug c/28675] ICE in extract_insn, at recog.c:2084 (nrecognizable insn) [arm]
--- Comment #1 from mkl at pengutronix dot de 2006-08-10 09:10 --- Created an attachment (id=12056) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12056action=view) small testcase to trigger the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28675
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #10 from mkl at pengutronix dot de 2006-08-08 13:31 --- Created an attachment (id=12042) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12042action=view) fix target linker emulation for arm elf and eabi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
[Bug target/16350] gcc only understands little endian ARM systems
--- Comment #11 from mkl at pengutronix dot de 2006-08-08 13:33 --- (In reply to comment #9) Created an attachment (id=11245) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11245action=view) [edit] gcc-4.1.0-arm-bigendian.patch gcc-4.1.x needs slight tweak since all the ARM_FLAG_* defines have been cut this patch applies with a little fuzz to mainline I've rediffed that patch against 4.1.1. If you try to build a big-endian eabi toolchain, you need another fix (see patch of gcc/config/arm/linux-eabi.h) -- mkl at pengutronix dot de changed: What|Removed |Added CC||r dot schwebel at ||pengutronix dot de, mkl at ||pengutronix dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16350
