This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug inline-asm/13079] Function calls overwrite stack data
- From: "bmills at andrew dot cmu dot edu" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 16 Nov 2003 23:11:41 -0000
- Subject: [Bug inline-asm/13079] Function calls overwrite stack data
- References: <20031116214417.13079.bmills@andrew.cmu.edu>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From bmills at andrew dot cmu dot edu 2003-11-16 23:11 -------
Correct compilation of code is something that programmers need to be able to
rely on. IF GCC claims to support inline assembly then it should support it in
a robust and bug-free manner, ensuring that the program will compile correctly
if the programmer has given GCC appropriate information about what they are
doing (in this case, clobbering the stack pointer, as indicated in the code).
There are clearly only two reasonable things GCC could do in this instance --
either put the stack pointer back where it was before making the function call,
or advance the stack pointer before writing the function argument. Either is
arguably correct behaviour; however, the current behaviour is not.
If I wanted to use only high-level language constructs, I certainly wouldn't be
writing in C. I'd write in a safer, higher-level language. The whole point of
C is to be able to write in something that can access the machine at a very low
level and do so correctly. Certainly, I could write my code in assembly -- but,
by that argument, GCC and C are both useless, because I "should" just write all
of my low-level code in assembly and write the rest in some higher-level language.
"That's not what it was designed for" has never been a valid argument in the
development of computers; I suspect it never will be. If a specification
exists, it should be followed, and if uncommon cases exist they must still
generate correct code, even if it may cause inefficient code in other cases.
Programmers need to be able to trust their compilers to generate correct code
regardless of whether they are using common features or uncommon ones.
Optimization *must* preserve correctness of code, or it is useless. The error
here is not the use of assembly code or the clobbering of the stack pointer, but
rather GCC's utter failure to realize that function calls depend on that value.
If the optimizer has parts that can't handle inline assembly, it shouldn't be
trying to optimize through the assembly. Also, this is clearly not a bug
related to the fact that GCC is an optimizing compiler, because it occurs with -O0.
Moreover, a bug in the calling convention in the presence of inline assembly may
be indicative of a much larger bug in register allocation relating to function
calls that manifests itself in a much more subtle way. If you want to just
dismiss it by saying "inline assembly is broken", you also have to add "function
calls are broken" and "stack allocation is broken", which are certainly not to
be taken lightly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13079