Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!riley From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley) Newsgroups: comp.sys.amiga.tech Subject: Re: Lattice C 5.xx optimizer & vt100 2.9 Message-ID: <9201@batcomputer.tn.cornell.edu> Date: 2 Nov 89 17:34:18 GMT References: <44@e2big.dec.com> Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley) Organization: Cornell Theory Center, Cornell University, Ithaca NY Lines: 29 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.