https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122976
--- Comment #4 from Jacek Sieka <arnetheduck at gmail dot com> --- Created attachment 62989 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62989&action=edit Patch that makes the code work I've found a minimal change that makes the problem go away: moving the affected variable to a global and the code runs correctly. This change is "safe" in the sense that the function is not reentrant and the variable has a short-lived scope that always starts with a memset(0), so it does not change the overall semantics of the function. > That sounds like maybe a misuse of the malloc attribute ... How would this manifest? By "the equivalent of", I mean that we call `_ZN3rlp10eqdestroy_E3varIN3rlp3RlpEE` which is a wrapper that indirectly calls `free` after a few more (trivial) layers - we do not set any attributes (other than visibility) on these wrapper functions. The definitions of the wrappers are somewhat spread out over the various TUs involved and its plausible that when compiling with -flto, they all get inlined so that the problematic code "sees" the malloc attribute on `free` itself (as `glibc` provides it). Another thing I've tried is to simply `printf` the pointer just before `_ZN3rlp10eqdestroy_E3varIN3rlp3RlpEE` is called to see what value it has - when doing this, the problem goes away and the code seems to be correctly compiled, ie the extra "read" of the pointer changes the code sufficiently that it works.
