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