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.