This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
- From: "ian at airs dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 30 Jun 2007 18:08:41 -0000
- Subject: [Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame
- References: <bug-32475-3760@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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