On 1/10/19 10:23 PM, Richard Sandiford wrote: > Segher Boessenkool <seg...@kernel.crashing.org> writes: >> On Tue, Jan 08, 2019 at 12:03:06PM +0000, Richard Sandiford wrote: >>> Bernd Edlinger <bernd.edlin...@hotmail.de> writes: >>>> Meanwhile I found out, that the stack clobber has only been ignored up to >>>> gcc-5 (at least with lra targets, not really sure about reload targets). >>>> From gcc-6 on, with the exception of PR arm/77904 which was a regression >>>> due >>>> to the underlying lra change, but fixed later, and back-ported to >>>> gcc-6.3.0, >>>> this works for all targets I tried so far. >>>> >>>> To me, it starts to look like a rather unique and useful feature, that I >>>> would >>>> like to keep working. >>> >>> Not sure what you mean by "unique". But forcing a frame is a bit of >>> a slippery concept. Force it where? For the asm only, or the whole >>> function? This depends on optimisation and hasn't been consistent >>> across GCC versions, since it depends on the shrink-wrapping >>> optimisation. (There was a similar controversy a while ago about >>> to what extent -fno-omit-frame-pointer should "force a frame".) >> >> It's not forcing a frame currently: it's just setting frame_pointer_needed. >> Whatever happens from that is the target's business. > > Do you mean the asm clobber or -fno-omit-frame-pointer? If the option, > then yeah, and that was exactly what was controversial :-) >
Yes, what I meant is the asm clobber sets frame_pointer_needed, on the function where this asm is used, that sounded to me like it would have an impact on the frame pointer. What I also expected, is that if an asm is accessing a local via "m" then the a SP+x reference will be elimitated to a FP+x, reference, which would allow the asm to push something on the stack, and the memory references would remain valid, as long as the stack is _restored_, again in the same asm. I mean in case of register shortage. I was not thinking about noreturn at all. But if -fno-omit-frame-pointer does the same, and that is not sufficient to for forcing a frame pointer, because it is a target dependent, then I wonder how ASAN is supposed to work on such a target. But anyway I guess, your patch is fine. Thanks Bernd.
