On Sun, 18 May 2014, Sandra Loosemore wrote: > Hmmmm, I'm guessing this was some concern about invalid code motion around a > setjmp. Our original analysis document lists "F does not call setjmp" as a > requirement for the optimization, so this was probably a case where we were > being excessively conservative.
Reading my internal analysis from 24 Nov 2005, it was in terms of converting a function-local static variable to automatic. The concern may well have been about "the values of objects of automatic storage duration that are local to the function containing the invocation of the corresponding setjmp macro that do not have volatile-qualified type and have been changed between the setjmp invocation and longjmp call are indeterminate" meaning that program that's valid when the variable is static can become invalid on converting it to automatic. Of course that depends on the particular uses of the variable (whether it's possible for it to be changed between the two calls); I think we can presume the existing optimizations (that deal with everything except the final store) already deal with keeping the transformations valid in the presence of setjmp / longjmp. -- Joseph S. Myers jos...@codesourcery.com
