[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters

["rogerio at rilhas dot com" <gcc-bugzilla@gcc.gnu.org>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4182 bytes --]



------- 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