[Bug rtl-optimization/125728] [16/17 Regression] M68k: m68k-elf-gcc generates code that raises address error exception in certain circumstances

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Drea Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|M68k: m68k-elf-gcc          |[16/17 Regression] M68k:
                   |generates code that raises  |m68k-elf-gcc generates code
                   |address error exception in  |that raises address error
                   |certain circumstances       |exception in certain
                   |                            |circumstances
          Component|target                      |rtl-optimization
   Last reconfirmed|                            |2026-08-07
                 CC|                            |pinskia at gcc dot gnu.org
     Ever confirmed|0                           |1
   Target Milestone|---                         |16.3
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Drea Pinski <pinskia at gcc dot gnu.org> ---
>From late-combine-1:
trying to combine definition of r37 in:
    6: r37:QI=[`foo']&0x7
into:
    7: r38:SI=zero_extend(r37:QI)
      REG_DEAD r37:QI
successfully matched this instruction to andsi3_internal:
(set (reg:SI 38 [ _2 ])
    (and:SI (mem/c:SI (const:SI (plus:SI (symbol_ref:SI ("foo") [flags 0x2] 
<var_decl 0x79bb1fb3b980 foo>)
                    (const_int -3 [0xfffffffffffffffd]))) [0 fooD.1888+-3 S4
A8])
        (const_int 7 [0x7])))


I would have expected rtl_hooks.gen_lowpart_no_emit to return null for the
subreg generation but maybe because foo was originally aligned to 4 bytes,
things go down hill because of big-endian-ness and a paradoxical sub reg.
Maybe there is another bug about a similar thing ...