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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=49330,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=53705

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
    3: NOTE_INSN_FUNCTION_BEG
    8: r134:DI=const(`g'+0x44)
    9: {r133:DI=frame:DI-0x4c;clobber flags:CC;}
      REG_UNUSED flags:CC
...
   56: r129:DI=const(`g'+0x4c)
   57: {r129:DI=r129:DI&0xfffffffffffffff8;clobber flags:CC;}
      REG_UNUSED flags:CC
      REG_EQUAL const(`g'+0x4c)&0xfffffffffffffff8
   58: {r118:DI=r134:DI-r129:DI;clobber flags:CC;}
      REG_DEAD r134:DI
      REG_UNUSED flags:CC
      REG_EQUAL const(`g'+0x44)-r129:DI
   59: {r119:DI=r133:DI-r118:DI;clobber flags:CC;}
      REG_DEAD r133:DI
      REG_UNUSED flags:CC

so the source is

  &e.. - ((&g+0x44) - (&g+0x44)&0xfff...8)

that is, the original source adjusted by the alignment prologue amount
which is aligning the destination.  That's a classical example for where
find_base_term is confused.  I'm not sure there's a way to "obfuscate"
things here.  I think find_base_term ignores paths with & (align ops)
but it goes down the subtract base path here.  So maybe instead of
subtracting using & (align-1) for that would work.

Reply via email to