[Bug target/53386] New: Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Bug #: 53386 Summary: Bad assembly code produced for m68000 Classification: Unclassified Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: lja...@gmail.com Hi, I'm currently using gcc 4.2.4 to build uClinux for a 68000 target (68HC000 cpu). I've update my toolchain to newer tool versions but now gcc (4.6.4) is producing bad assembly for this target. I'm almost sure that it is producing only 68020 assembly code and/or ignoring the -m68000 switch (I checked that when specifying -m68000 or -m68020 gcc is producing the same assembly code). Here is a simple testcase (a line from the kernel where my system was hanging): C instruction (from 'proc_net_ns_init' function): [...] memcpy(netd->name, "net", 4); [...] 4.2.4 assembly output: [...] 60:157c 006e 004d moveb #110,%a2@(77) 66:157c 0065 004e moveb #101,%a2@(78) 6c:157c 0074 004f moveb #116,%a2@(79) 72:422a 0050 clrb %a2@(80) [...] 4.6.4 assembly output: [...] 42:217c 6e65 7400 movel #1852142592,%a0@(77) 48:004d [...] Since the opcode movel has an odd displacement, it is causing an address/bus error exception, halting the cpu. Another difference I've noticed while tracing the above issue, is the way parameters are placed in the stack for the function call: 4.2.4 assembly: [...] movel absolute_address,%sp- [...] 4.6.4 assembly: [...] moveaw value1,%a0 addal value2,%a0 movel %a0@,%sp- [...] This is not critical but at a first look, it look it has slower execution and produces larger code (is this correct?). Command line used in this test (from the kernel build): m68k-uclinux-gcc -m68000 -Wp,-MD,net/sunrpc/.rpc_pipe.o.d -isystem /usr/local/lib/gcc/m68k-uclinux/4.5.1/include -I/root/m68k/20120401/uClinux-dist/linux-3.x/arch/m68k/include -Iarch/m68k/include/generated -Iinclude -include /root/m68k/20120401/uClinux-dist/linux-3.x/include/linux/kconfig.h -D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -O2 -pipe -DUTS_SYSNAME=\"uClinux\" -D__uClinux__ -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -DCC_HAVE_ASM_GOTO -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(rpc_pipe)" -D"KBUILD_MODNAME=KBUILD_STR(sunrpc)" -c -o fs/proc/proc_net.o fs/proc/proc_net.c Anyone knows what is the latest gcc version where code for 68000 is still ok? (I didn't want to go and build version by version until I find the one that's broken...) Regards, Luis Alves
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Luis Alves changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.6.4 |4.6.3 Resolution||INVALID --- Comment #2 from Luis Alves 2012-05-17 10:18:47 UTC --- Thanks a lot Andreas, Changes those flags to true and it's working good now. Also a minor correction: I was trying to build gcc 4.6.3 (not 4.6.4). (I've changed status to RESOLVED-INVALID since this is not a bug but a configuration issue) Regards, Luis Alves
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #3 from Luis Alves 2012-05-17 10:19:11 UTC --- Thanks a lot Andreas, Changed those flags to true and it's working good now. Also a minor correction: I was trying to build gcc 4.6.3 (not 4.6.4). (I've changed status to RESOLVED-INVALID since this is not a bug but a configuration issue) Regards, Luis Alves
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Luis Alves changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Luis Alves 2012-05-17 11:00:19 UTC --- I agree with that. I'll just leave it UNCONFIRMED until someone decides what to do with this.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #9 from Luis Alves 2012-05-17 14:29:07 UTC --- Thanks Mikael, But... will I have any (future) problems if I just change the flags in the ? In a small test I've made that solutions seems to produce good code for the 68000 but I'm afraid I might end up with a 'crippled' gcc.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #12 from Luis Alves 2012-05-17 15:44:12 UTC --- (In reply to comment #10) > See the gcc-patches thread I referred to in #c8, gcc-4.3 also changed > low-level > ABI details, with the consequence that gcc-4.2 and gcc-4.3 generate > incompatible code for m68k-uclinux. If you want 4.3 and newer to behave as > 4.2 > and older you should use m68k-uclinuxoldabi. Patching m68k/linux.h might > work, > but it's not a supported configuration. Just wanted to add that I use gcc to fully build a uClinux-dist (kernel+userland binaries) so it really doesn't bother me if the gcc >= 4.3 generates incompatible code with gcc-4.2. And I dare to say that this is the case for everyone using uClinux.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #13 from Luis Alves 2012-05-18 17:00:11 UTC --- I've built gcc with the m68k/linux.h patched for the 68000 but it's not working as expected. As test I've used linux kernel 3.3 Results are compared to the use of gcc-4.2.4 vs gcc-4.6.3 (gcc-4.7.0 doesn't even build itself because of an ICE). (Using the same kernel configuration, only changed gcc version) Kernel Size: 4.2.4: 2158592 bytes 4.6.3: 2244608 bytes (around 4% increase) Using 4.2.4 kernel boots as expected and everything works fine. With 4.6.3 the kernel boots and after a few seconds starts a non-stop SPAM of BUGs: [...] BUG: scheduling while atomic: ksoftirqd/0/3/0x [...] BUG: scheduling while atomic: kthreadd/2/0x [...] BUG: scheduling while atomic: kworker/0:0/4/0x0402 [...] Until eventually panics. Anyway, building gcc for target "m68k-uclinuxoldabi" is a bit awkward. I've tried to build and the message I got is that target will be removed soon. Also it would give a lot of work to integrate it with the existing tools because of the resulting prefix (binutils, elf2flt, ...). As of "gcc -m68000" not generating correct code for the 68000 I would still say that IT IS a gcc bug...
