This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
- From: "rogerio at rilhas dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Aug 2010 17:50:15 -0000
- Subject: [Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
- References: <bug-45265-19547@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #24 from rogerio at rilhas dot com 2010-08-12 17:50 -------
(In reply to comment #20)
I couldn't resist to comming back (you respond very quickly, kudos!, I'm not
used to that! :-)
> Just for fun, I compiled this test case with various levels of optimization.
> It works fine without optimization or with -O1, but segfaults at -O2 or -O3.
The script I sent you does not request optimizations and segfaults.
> That indicates that the program only works by coincidence, not by design -
> you've made assumptions about how GCC will interpret your sources, and those
> assumptions are wrong. In this case, your assumption is that "bug_example_2"
> will always be a separate function, and will always be called as a separate
> function, and thus that you can assume some knowledge of the internals of the
> stack layout.
When I don«t request optimizations my interpretation is right. A function
declaration (that doesn't specifically request inline) is a function. I don't
know if C99 says it (probably does, in a C-sense function), but cdecl does.
> The C language does *not* require that a function which is called, be called as
> a separate function, only that the semantics of the call be the same as far as
> the C language requires. The C language allows GCC to implement that function
> call in any way it chooses - and GCC chooses to implement it without actually
> doing a function call, but by copying the function body to the callee. At
> least, it does when optimizing. Without optimization, it *happens* to do what
> you expect.
Compile it like I did in the script (without optimizations) and see it fail.
> It will also do what you expect if bug_example_2 and bug_example
> are in separate source files - *then* the "cdecl" standard you refer to
> applies, because cross-object calls are limited by the compatibility standards.
> However - if you use gcc to link as well, gcc has the option of optimizing
> those calls *also*.
> So, GCC is "cdecl" compliant because *if* there's a function call, *then* the
> *stack* is laid out the same. However, the "cdecl" standard does *not* require
> that your program work, because C allows the optimizer to avoid the actual
> function call completely when the callee and caller are in the same scope.
Incorrect, code should not be optimized if I don't request it. If I do I have
to live without cdecl compliance, obviously, as I don't know of any compiler
that has an option like "optimize_as_possible_but_keep_cdecl_always". My point
is for non-optimized code, and that is why I included the scrip I used to build
it.
> Note: you can tell gcc to not inline a function with __attribute__((noinline))
> in which case a call to it is always an actual call to it, but it would be
> easier to just use the standard methods for accessing parameters so that it
> *always* works.
Agreed. But I'm determining the addresses of the parameters just to check GCC's
conformity, remember? So don't you worry about how easy the code is for me, I
will deal with that.
I just tried the attribute and didn't make any difference in the code, and is
still not cdecl. I'm sure it is not a bug in GCC though...
> Also, with full optimization enabled, your code crashes with MSVC also.
Right. As explained, this bug report is about non-optimized code. I also didn't
expect Microsoft's code to not crash if optimized (nor tried it until your
comment).
I don't think I ever mentioned optimizations in this bug report, I did it in
the "variable parameters" bug report bucause that was how I initially got it to
crash and had no way to report it to you (it crashed without optimizations in a
larger program that I could not send to you), but I later sent you a full
report (with snapshots and all in comment #51) a non-optimized version that
crashed. Here I could easilly show it to crash when not optimized, and so I
could live with disabling optimizations to get the addresses to be returned
properly.
> Please file a bug report with Microsoft.
No need. Their code *NEVER* crashes if I don't request optimizations.
This is it, I must resist! Bye!! :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265