https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98692
jseward at acm dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jseward at acm dot org
--- Comment #19 from jseward at acm dot org ---
(In reply to Mark Wielaard from comment #18)
(expanding marginally on Mark's comment)
Currently the Memcheck ppc64be and ppc64le ports assume that the redzone
(the 288 bytes below SP) is volatile across both calls and returns, and it
enforces this behaviour by painting that area of memory as "undefined" for
both calls and returns. But the optimisation discussed here appears to carry
live data across a return (that's what a "blr" is, right?)
So in effect the problem occurs because this optimisation changes the
ABI semantics that Memcheck has thus far assumed. As Mark says, we can
"fix" this just by disabling the zap-on-return instrumentation behaviour,
but that comes at the cost of completely losing the ability to detect
genuinely incorrect uses of the redzone across a return.
