[Bug target/53386] Bad assembly code produced for m68000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Jeffrey A. Law changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution|--- |INVALID --- Comment #15 from Jeffrey A. Law --- Nothing we can do without a testcase.
[Bug target/53386] Bad assembly code produced for m68000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2015-01-19 CC||law at redhat dot com Ever confirmed|0 |1 --- Comment #14 from Jeffrey A. Law law at redhat dot com --- We really need a testcase for the issue raised in c#13. Without a reasonable testcase, there really isn't anything we can do.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #13 from Luis Alves ljalvs at gmail dot com 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...
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #1 from Andreas Schwab sch...@linux-m68k.org 2012-05-17 08:23:45 UTC --- config/m68k/linux.h: /* for 68k machines this only needs to be TRUE for the 68000 */ #undef STRICT_ALIGNMENT #define STRICT_ALIGNMENT 0 #undef M68K_HONOR_TARGET_STRICT_ALIGNMENT #define M68K_HONOR_TARGET_STRICT_ALIGNMENT 0
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Luis Alves ljalvs at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Version|4.6.4 |4.6.3 Resolution||INVALID --- Comment #2 from Luis Alves ljalvs at gmail dot com 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 ljalvs at gmail dot com 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 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2012-05-17 10:52:55 UTC --- (In reply to comment #3) (I've changed status to RESOLVED-INVALID since this is not a bug but a configuration issue) I'm not so sure about that. For supported target triplets you are not supposed to have to edit any gcc sources to get a correct compiler.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Luis Alves ljalvs at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Luis Alves ljalvs at gmail dot com 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 #6 from Mikael Pettersson mikpe at it dot uu.se 2012-05-17 11:09:08 UTC --- The behaviour changed between gcc-4.2.4 (ok) and gcc-4.3.6 (bad).
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386
--- Comment #7 from Mikael Pettersson mikpe at it dot uu.se 2012-05-17
11:31:35 UTC ---
gcc-4.3.x changed gcc/config.gcc:
--- gcc-4.2.4/gcc/config.gcc2008-03-13 20:11:43.0 +0100
+++ gcc-4.3.6/gcc/config.gcc2011-02-25 00:02:14.0 +0100
...
-m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux with
uClibc
- tm_file=m68k/m68k.h m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h
m68k/uclinux.h
- tm_defines=${tm_defines} MOTOROLA USE_GAS
- tmake_file=m68k/t-uclinux
+m68k-*-uclinuxoldabi*) # Motorola m68k/ColdFire running uClinux
+ # with uClibc, using the original
+ # m68k-elf-based ABI
+ default_m68k_cpu=68020
+ default_cf_cpu=5206
+ tm_file=${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h
m68k/uclinux-oldabi.h
+ tm_defines=${tm_defines} MOTOROLA=1
+ tmake_file=m68k/t-floatlib m68k/t-uclinux
+ use_fixproto=no
+ ;;
+m68k-*-uclinux*) # Motorola m68k/ColdFire running uClinux
+ # with uClibc, using the new GNU/Linux-style
+ # ABI.
+ default_m68k_cpu=68020
+ default_cf_cpu=5206
+ tm_file=${tm_file} dbxelf.h elfos.h svr4.h linux.h flat.h m68k/linux.h
m68k/uclinux.h ./sysroot-suffix.h
+ tm_defines=${tm_defines} MOTOROLA=1 UCLIBC_DEFAULT=1
+ extra_options=${extra_options} linux.opt
+ tmake_file=m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs
use_fixproto=no
;;
Upping the default m68k cpu to 020 is suspicious, but the real problem is the
inclusion of m68k/linux.h in tm_files, as that disables strict-alignment
support, even when compiling with an explicit -m68000 option.
I don't know anthing about the uClinux m68k old and new ABIs, but it looks
like you will get correct behaviour if you build for m68k-uclinuxoldabi
--with-cpu=m68000.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #8 from Mikael Pettersson mikpe at it dot uu.se 2012-05-17 12:57:20 UTC --- Fallout from a deliberate ABI change in 4.3.x, see http://gcc.gnu.org/ml/gcc-patches/2007-01/msg00773.html and its followups. I don't like the way an existing target triplet was reassigned an entirely different meaning, but it's too late to do anything about that now. Configuring for m68k-uclinuxoldabi is the correct solution for gcc-4.3 and newer if you need m68000-compatible code. You can close this as invalid now.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #9 from Luis Alves ljalvs at gmail dot com 2012-05-17 14:29:07 UTC --- Thanks Mikael, But... will I have any (future) problems if I just change the flags in the config/m68k/linux.h ? 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 #10 from Mikael Pettersson mikpe at it dot uu.se 2012-05-17 15:02:51 UTC --- 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.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Severity|blocker |normal --- Comment #11 from Andreas Schwab sch...@linux-m68k.org 2012-05-17 15:30:09 UTC --- I would be ok with changing linux.h to honor -mstrict-align, though m68k_return_in_memory would have to be left out. The default will of course continue to be -mno-strict-align.
[Bug target/53386] Bad assembly code produced for m68000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53386 --- Comment #12 from Luis Alves ljalvs at gmail dot com 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.
