[Bug c/21160] how to force a variable into the stack?

["joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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