erroneous "clobbering" warning when using setjmp() (reproducible, w/ small source)

Johan Lindh
Wed Oct 20 04:55:00 GMT 1999

>> I understand your reasoning. I would now like to submit to you that
>> inlining functions containing setjmp (and vfork?) is, if not an outright
>> bug, then at least very bad judgement.
>Ok. That would be a different bug report from the original one: the
>compiler rightfully warns that the variables might be clobbered, as
>this is exactly what happens. So you agree that the warning represents
>the facts, don't you?

Yes, I do.

>Whether -finline-functions should inline functions containing calls to
>setjmp is debatable. You cannot rely on the C standard to give you
>guidance here, as this option is an extension over standard C.


>Instead, the behaviour should reflect the documentation and 'common
>sense'. My intuition is that this option enables aggressive inlining:
>If you don't want this, use the __inline__ keyword selectively.

Aggressive is good; suicidal is bad. Personally, I simply think that
no-one thought of this situation occuring, and so no provisions have
been made for it.

>One safe way is to put the respective functions in a separate
>translation unit - gcc does not perform inlining at link time
>(although other compilers do).

A good suggestion. Too bad the library is all in one source file for
portability and ease-of-use. =/

Well, I'm thinking of splitting it up into several files for other reasons,
so if I ever do that I'll make sure to put the setjmp/longjmp functions
in a separate file.

>Now, I think it would be certainly possible (and perhaps even easy) to
>avoid inlining of functions that call setjmp or longjmp. If you find a
>patch for gcc solving the problem, please submit it to

"Find a patch"? You mean, "write a patch"? Well, I think I'll leave that to
the people who do it best, the current maintainers. ;)

I think my suggestion to avoid inlining functions that contain setjmp
etc is a good one, and if one of the maintainers think so too, I can hope
it will happen in the near future.

In the meanwhile, I'll just add a section to my FAQ about inlining with gcc.

Thanks for helping me understand the problem, Martin, and keep up the
good work!


More information about the Gcc-bugs mailing list