pete@e2big.dec.com (Pete Snider) (11/02/89)
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 tried 5.0, 5.02, and 5.04 'go' with the same results. Happy bug hunting. :-) -pete [ No, I don't even speak for myself. ]
acs@pccuts.pcc.amdahl.com (Tony Sumrall) (11/02/89)
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 tried 5.0, 5.02, and 5.04 'go' with the same results. Happy
:bug hunting. :-)
Fortunately the distributed version was compiled with Aztec 3.06a. Well,
some folks would say fortunately :-).
:-pete
:[ No, I don't even speak for myself. ]
---
Tony Sumrall author of VT100 2.9 (and 2.8a and 2.8 and...)
acs@pccuts.pcc.amdahl.com <=> amdahl!pccuts!acs
[ Opinions expressed herein are the author's and should not be construed
to reflect the views of Amdahl Corp. ]riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (11/03/89)
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.
new@udel.edu (Darren New) (11/03/89)
Can anybody tell me where to contact the individual at Lattice responsible for the 5.04 upgrades? I never received mine. Either a phone number or an internet address would be OK. Lattice BBS is inaccessable to me. Thanks! -- Darren
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (11/03/89)
In article <3220@nigel.udel.EDU> new@udel.edu (Darren New) writes: >Can anybody tell me where to contact the individual at Lattice >responsible for the 5.04 upgrades? I never received mine. >Either a phone number or an internet address would be OK. (312) 916-1600, I believe. After 11/11, the area code changes to 708. I notified them last Friday that mine hadn't arrived, and a replacement showed up today. I tried compiling init.c in vt100-2.9, and verified that the 5.04 go has the same problem as the 5.02 go (described in a previous article with this subject). On the plus side, 5.04 does fix all three bugs in 5.02 that I reported to Lattice, so bug reports do count! -Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell U.
bleys@tronsbox.UUCP (bleys) (11/04/89)
>Fortunately the distributed version was compiled with Aztec 3.06a. Well, >some folks would say fortunately :-). Heh. The "C Notes From the C Group" column in AC, by Stephen Kemp, has been using what looks like an Manx-specific function, scdir(). It looks like it searches a directory for a file path, using wildcards, and returns a file pointer. Anybody who knows Lattice and Manx who can let me know exactly what the little bugger does, and a Lattice equivelant? I'm new to C, and it's tough enough to learn this language without having to worry about compiler idiosyncracies!
new@udel.edu (Darren New) (11/07/89)
In article <9207@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes: >In article <3220@nigel.udel.EDU> new@udel.edu (Darren New) writes: >>Can anybody tell me where to contact the individual at Lattice >>responsible for the 5.04 upgrades? I never received mine. >>Either a phone number or an internet address would be OK. >(312) 916-1600, I believe. After 11/11, the area code changes to 708. Zowie! I called them early in the morning and the disk showed up in the mail the next day! I'm suprised that the Post Office is that fast, let alone a free upgrade from a software company. Hats off to Lattice. -- Darren
walker@sas.UUCP (Doug Walker) (11/07/89)
In article <3220@nigel.udel.EDU> new@udel.edu (Darren New) writes: >Can anybody tell me where to contact the individual at Lattice >responsible for the 5.04 upgrades? I never received mine. Lattice tech support is (312)916-1100 Fax them at (312)916-1190 ***** *|_o_o|\\ Doug Walker, Software Distiller *|. o.| || | o |// "It is well to remember that evil is a pretty bad thing." ====== usenet: ...mcnc!rti!sas!walker plink: dwalker bix: djwalker