[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847 ⎓ changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from ⎓ --- I can confirm that everything works as it should with m68k-unknown-elf-gcc/g++ build with crosstool-NG. But I would still prefer that m68k-linux-* refuses to work with the older CPUs or something like that. This problem could potentially discourage less experienced people away from experimenting with m68k.
[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847 --- Comment #4 from ⎓ --- Hmm... I was hoping to get away with the readily available compiler, and I thought that it's actually used for CPU32. Ok, I'll try then with a specific one tomorrow. But still, ABI can't request that all bytes in a uint8_t array are aligned. I mean, you can never expect uint8_t pointer to be aligned, regardless of the used ABI. On the other hand, according to Wiki: > The 68020 had no alignment restrictions on data access. So that could explain it. If it really is the wrong compiler kind, then I've gotta admit, this is the second time something like that happened to me because of my laziness to build a compiler. Shouldn't the old and new m68k be separated or something, so a problem like this can't happen? Maybe another issue for that?
[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847 --- Comment #3 from Mikael Pettersson --- I am almost certain that you need to use an m68k-elf toolchain rather than an m68k-linux-gnu one for the CPU32. The linux toolchain targets the classic '020 CPU or above (030, 040, or 060) and mandates the Linux ABI, which affects alignment among other things.
[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847
--- Comment #2 from ⎓ ---
The same thing is with other way around. I.e.:
void ntoh(uint16_t idata, uint8_t *odata) {
odata[0] = idata >> 8;
odata[1] = idata & 0xff;
}
results with:
move.l 8(%sp),%a0
move.w 6(%sp),(%a0)
rts
I've tried with both -mstrict-align and -mno-strict-align and there are no
differences in the produced assembly file (generated with -S).
[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Component|rtl-optimization|target Last reconfirmed||2021-03-31 --- Comment #1 from Richard Biener --- At least 'odata' is aligned according to your source. Did you try -mstrict-align? It looks like this is not the default.
