------- Comment #13 from ian at airs dot com 2007-06-30 18:08 ------- The problem here is that although the stack pointer is not used in the function, adjusting it does reserve space on the stack for the local variables which are used. The local variables are accessed via the frame pointer with a negative offset. Deleting the adjustment of the stack pointer is causing that the reference to be implicitly invalid. This test case makes the problem obvious via an asm which essentially does a function call which the compiler doesn't know about. If the asm weren't there, though, there would still be a difficult to diagnose problem in that an interrupt at the wrong time would corrupt the value of the local variables.
One possible approach to this is that DF should note that any reference to a local variable via the frame pointer is implicitly a use of the stack pointer. Note that this doesn't necessarily mean a negative offset from the frame pointer, although it does in this case. On processors like the Thumb even local variables are accessed as positive offsets from the frame pointer, and parameters are accessed by larger positive offsets. We also need to consider whether any asm statement is a use of the stack pointer. It may be that DF should treat an asm statement however it treats a function call with regard to uses of the stack pointer. A non-volatile asm would be a const call, and a volatile asm would be an ordinary call. I'm not completely sure about that, but it seems worth considering. A simpler approach would be for DCE to simply not remove adjustments to the stack pointer. I believe this would have to be done whether the adjustment was frame related or not. I think the fact that the instruction is frame related is probably a red herring here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475
