Dear all, testing gcc 4.9.0 toolchain for mcf5307 (coldfire) the code on target hangs (loops) on a 64 bit shift opration (between 2 nop's i put). I see that code (64 bit shift) is added from libgcc. ffc0ee2e <print_size>: ffc0ee2e: 4e56 ffd0 linkw %fp,#-48 ffc0ee32: 48d7 3c7c moveml %d2-%d6/%a2-%a5,%sp@ ffc0ee36: 2f2d 03d8 movel %a5@(984),%sp@- ffc0ee3a: 4282 clrl %d2 ffc0ee3c: 347c 003c moveaw #60,%a2 ffc0ee40: 266d 0008 moveal %a5@(8),%a3 ffc0ee44: 4e93 jsr %a3@ ffc0ee46: 588f addql #4,%sp ffc0ee48: 262d 051c movel %a5@(1308),%d3 ffc0ee4c: 4e71 nop ffc0ee4e: 2043 moveal %d3,%a0 ffc0ee50: 2f0a movel %a2,%sp@- ffc0ee52: 2f2e 000c movel %fp@(12),%sp@- ffc0ee56: 2f2e 0008 movel %fp@(8),%sp@- ffc0ee5a: 4e90 jsr %a0@ ffc0ee5c: 4fef 000c lea %sp@(12),%sp ffc0ee60: 2d40 fff8 movel %d0,%fp@(-8) ffc0ee64: 2d41 fffc movel %d1,%fp@(-4) ffc0ee68: 4e71 nop ffc0ee6a: 2843 moveal %d3,%a4 ffc0ee6c: 202e fff8 movel %fp@(-8),%d0 ffc0ee70: 222e fffc movel %fp@(-4),%d1 ffc0ee74: 2800 movel %d0,%d4 ffc0ee76: 8881 orl %d1,%d4 ffc0ee78: 670a beqs ffc0ee84 <print_size+0x56> ffc0ee7a: 206d 03d0 moveal %a5@(976),%a0 ffc0ee7e: 1430 2800 moveb %a0@(0000000000000000,%d2:l),%d2 I don't see anything strange in the opcodes, anyway, execution stops somewhere between the 2 nops.
Please read <http://gcc.gnu.org/bugs/>.
Hi, finally i have more details. I reproduce this issue on toolchains built for x86_64, from gcc 4.9.0 to latest gcc 5.2.0. Compiling options don't make great differences, i am actually using -ggdb -Wall -fno-builtin -ffreestanding -O0 -pipe -mcpu=5307 and forcing libgcc __lshrdi3 to be called from c source. The line .short 0x48e7 create the issue. It brings of course to a fault. __lshrdi3 (DWtype u, shift_count_type b) { ffc1094c: 4e56 0000 linkw %fp,#0 ffc10950: 48e7 .short 0x48e7 I attach all i have to help you.
Created attachment 36787 [details] code that generate the fault
Here what i see when i step into the function: http://imgur.com/2802Ob5 I build on linux $ cat /proc/version Linux version 4.1.7001 (root@jerusalem) (gcc version 5.2.1 20150911 (Debian 5.2.1-17) ) #1 SMP Sat Sep 19 15:29:17 CEST 2015 Compiling with -Wall -Wextra doesn't show anything wrong. Same using -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations, no changes, i still see 0x20000768 linkw %fp,#0 0x2000076c .short 0x48e7 0x2000076e movew %d0,%d4 0x20000770 movel %fp@(8),%d2 0x20000774 movel %fp@(12),%d1 0x20000778 movel %fp@(16),%d3 ... -fsanitize=undefined produces compile time errors intead: /home/angelo/archivio/aziende/sysam/u-boot-extras/4.9.0_issue/main.c|30|undefined reference to `__ubsan_handle_type_mismatch'| Command line that reproduce the issue: Running command: make -f makefile /opt/toolchains/m68k/gcc-5.2.0-nolibc/bin/m68k-linux-gcc -Wall -Wextra -ggdb -fno-builtin -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -ffreestanding -O0 -pipe -mcpu=5307 -c -o main.o main.c /opt/toolchains/m68k/gcc-5.2.0-nolibc/bin/m68k-linux-ld.bfd -n -Bstatic -Tram.ld -Map test.map boot.o main.o -o test.bin -L /opt/toolchains/m68k/gcc-5.2.0-nolibc/lib/gcc/m68k-linux/5.2.0 -lgcc Process terminated with status 0 (0 minute(s), 0 second(s)) 0 error(s), 0 warning(s) (0 minute(s), 0 second(s)) Regards
Any news ? Trying also --with-arch=cf breaks the compilation. So i can't have in any way valid libgcc code i.e. for m5307.
What binutils version are you using? Have you tried a newer version of binutils first?
Hi Andrew, it is passed some time, i solved mainly the issue with a workaround. Yes i tested several binutils even last, but is more a matter of compiling the m68k/coldfire toolchain properly. Mainly, building if i build the toolchain for m68k with default flags, only m68000 default code is added in gcc multilibs (and it is used later when i buil m68k apps with 64 bit shift). While, if i try to to build with flags for coldfire (--with-arch=cf) this breaks the compilation, i should have reported some other error about here in bugtracking. My workaround was to copy libgcc.a and coldfire subfolder from another older working toolchain. Regards angelo
So close as invalid for this bug.