Should optimizing compilers automatically assign registers?

[Michael Meissner]

In article <596 at atcmpe.atcmp.nl> leo at atcmp.nl (Leo  Willems) writes:

| But I have a question on this subject:
| 
| Should an optimizer put autovar's in a register anyway? If you use
| setjmp/longjmp, on the return from setjmp via longjmp, automatic
| variables can not be trusted any more! If they are not in a register
| everything is fine, but else the reg-var's are overwritten with registervalues
| which were there at the time of the longjmp call.

ANSI says that all local variables whether register or not, that do
not have the volatile qualifier, can be trashed by setjmp/longjmp.

Implementors don't seem willing to have longjmp 'do the right thing'
(ie, completely unwind the stack, restoring registers -- for machines
with well defined frames, this is rather trivial -- for the two RISC
machines I'm familar with [MIPS, 88k], there is a lookaside table that
tells for each function, which registers are saved where, and what
register to use as the virtual frame pointer).

| This is in conflict with the manual page of setjmp/longjmp.
| (I realise the setjmp/longjmp implementation is not very portable, but their
| behaviour should be)
| 
| Is there an answer to this problem? (besides of not using setjmp/longjmp:-( )

Don't assume that any local variable has a meaningful value after
setjmp (and of course longjmp going through setjmp) returns.  No ifs,
ands, or buts.

GCC -Wall -O options will warn of live variables across setjmp calls.
--
Michael Meissner	email: meissner at osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Catproof is an oxymoron, Childproof is nearly so