A possible bug in g++ w/ -O option (SPARC)
Martin v. Loewis
Fri Dec 31 20:54:00 GMT 1999
> Anyway, I see your point. I attached the files
> you have requested. I need everyone's help
> because I failed to figure out this bug fix.
> Please let me know if you need something from
Thanks again for your report. After reviewing your code, I have a
number of comments.
1. Somehow, the preprocessor output got corrupted. The file test.ii I
got is 70964 bytes, the md5sum is
and it ends with the lines
Test top_level(__null );
Module& top = top_level8:
It is the last line that does not compile.
2. I was surprised by your extensive usage of the dollar sign ($) in
identifiers. While this is not strictly a problem, you should be
aware that this is a gcc extension, and not necessarily suppported
by other compilers.
3. I believe your program relies on undefined behaviour, which is
causing the problem you are seeing. As far as I understand, the
sequence of events is such:
A) somebody calls do_exec
B) this calls co_exec_1
C) $magic is false, so longjmp is not called
D) $magic is set to true, and setjmp is called
E) co_exec_1 and do_exec return
F) somehow, do_exec is called again, and calls co_exec_1 again
G) this time, $magic is 1, and the longjmp is performed
So in essence, you call longjmp after the function that did the
original setjmp call has already returned. The meaning of
setjmp/longjmp is defined in the C standard (the C++ standard
refers to that). They say, in section 7.13.2/2 (of C99)
# The longjmp function restores the environment saved by the most
# recent invocation of the setjmp macro in the same invocation of the
# program with the corresponding jmp_buf argument. If there has been
# no such invocation, or if the function containing the invocation of
# the setjmp macro has terminated execution 196) in the interim, or if
# the invocation of the setjmp macro was within the scope of an
# identifier with variably modified type and execution has left that
# scope in the interim, the behavior is undefined.
Footnote 196 elaborates
# For example, by executing a return statement or because another
# longjmp call has caused a transfer to a setjmp invocation in a
# function earlier in the set of nested calls.
This says you cannot re-enter a function call after it has been
terminated. Therefore, the compiler is right assuming that the longjmp
call will never transfer control to the setjmp call later in the same
function, and the bug is in your program.
Please let me know if you think I'm missing an important detail. If
not, there is no need to re-report any of your code.
More information about the Gcc-bugs