[Bug rtl-optimization/99847] New: Optimization breaks alignment on CPU32

[Bug rtl-optimization/99847] New: Optimization breaks alignment on CPU32

[m.frohiky at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847

            Bug ID: 99847
           Summary: Optimization breaks alignment on CPU32
           Product: gcc
           Version: 10.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: m.frohiky at gmail dot com
  Target Milestone: ---

For CPU32 architecture optimizes two byte accesses into a single word access,
without any regard that the original array may be unaligned.

So this code:

void ntoh(const uint8_t *idata, uint16_t *odata) {
    *odata = ((uint16_t)idata[0] << 8) | idata[1];
}

Compiled with -Os or -O2 produces:

        move.l 4(%sp),%a1
        move.l 8(%sp),%a0
        move.w (%a1),(%a0)
        rts

And if idata (address in register a1) is not aligned, the CPU will crash.

The compiler I'm using is m68k-linux-gnu-gcc (g++ has the same problem) which
comes from Debian repository. The exact version is "(Debian 10.2.1-6) 10.2.1
20210110"

Even if it's relying on exception handler to handle the unaligned data it makes
no sense because it's sooo much slower.

[Bug target/99847] Optimization breaks alignment on CPU32

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847

Richard Biener <rguenth at gcc dot gnu.org> 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 <rguenth at gcc dot gnu.org> ---
At least 'odata' is aligned according to your source.  Did you try
-mstrict-align?  It looks like this is not the default.

[Bug target/99847] Optimization breaks alignment on CPU32

[m.frohiky at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847

--- Comment #2 from ⎓ <m.frohiky at gmail dot com> ---
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

[mikpelinux at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847

--- Comment #3 from Mikael Pettersson <mikpelinux at gmail dot com> ---
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

[m.frohiky at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847

--- Comment #4 from ⎓ <m.frohiky at gmail dot com> ---
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

[m.frohiky at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847

⎓ <m.frohiky at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from ⎓ <m.frohiky at gmail dot com> ---
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.