------- Additional Comments From joseph at codesourcery dot com 2005-04-22 15:51 ------- Subject: Re: how to force a variable into the stack?
On Fri, 22 Apr 2005, pinskia at gcc dot gnu dot org wrote: > No you have not taken the address, as it will not escape or otherwise. > volatile in a local function is the > same as almost as a non register. > Another way to "fix" this would be do the following: > escape_function(&a); > and mark escape_function as no inline, but this might not work in the furture > as we might know that > escape_function does not escape that address, the way to work around that > would be make a static file > scope variable which gets assigned that pointer but even that might cause the > escapeness in the future > so the only correct way is mark the variable as volatile. > > -- > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Resolution| |INVALID You appear not to have noticed that the bug reporter pointed out an inconsistency between GCC's documentation and its behavior. Such an inconsistency is always a bug - in this case, a bug in the documentation - and you should not close a bug report concerning such an inconsistency until it has been fixed. The problem passage is that describing "candidates for register allocation", since GCC can now allocate variables, and parts of structure variables, to different registers and stack locations at different times. The other documentation concerning longjmp, in interface.texi and in trouble.texi, is quite correct: following the ISO C standard, the value of a non-volatile automatic variable changed between setjmp and longjmp is undefined and the only way to avoid this undefined behavior is to use "volatile". Even if the address escapes, the behavior is still undefined, although making the address escape might serve to avoid the warning (in cases where you know the variable in fact can't change between setjmp and longjmp) until there is fine-grained warning control, which we hope to have in GCC 4.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21160
