🚀 go-pugleaf

In article <44@e2big.dec.com> pete@e2big.dec.com (Pete Snider) writes:
>Last night I tried to recompile vt100 2.9 with the optimizer
>turned on.  The optimizer gave some warnings about "dead
>variable eliminatations" along with module name and varibles.
>Well, I tried to execute it anyway knowing anything could happen
>and I received a friendly visit from the local guru.  After
>some investigation the variables that were eliminated are being
>used.  In fact, one is used as a return value from the function.

I don't have 5.04 yet (got lost--Lattice is shipping a new one).  In 5.02
and 5.0, the message is not about dead variables--it's dead assignments.
These are the moral equivalent of "i = 0; i = 5;", where, if "i" is a
normal variable and this is a normal sequential program, the first assignment
can't possibly make any difference to the final result.  Not all the
assignments eliminated are this obvious (though at least one is!), but they
all seem to be correct, and are not the cause of your guru.

What is the cause is a completely different bug in go.  At least in the
5.02 incarnation, go is failing to keep a local variable in sync with the
value cached in a register.  The net result is that some code in init.c
ends up converting the bottom few bytes of memory to lowercase.  Bad things
happen when location 4 (sysbase) gets downcased.  If it's the same problem
in 5.04, I'll try to isolate it and submit a bug report to Lattice (if my
5.04 ever arrives).  In the meantime, don't compile init.c with the
optimizer.  All the other modules seem to optimize fine--I tested it out 
this morning.

-Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell U.