bonnetf@apo.esiee.fr (bonnet-franck) (10/16/90)
We found a strange bug in pascal compiler (Pascal compiler 68K Rev 8.7(271))
The source program follows :
----------------- CUT HERE ----------------------------
program b(input, output);
var princ: integer;
procedure p(var s:integer);
begin
s := 1;
writeln(s);
end;
begin
p(princ);
writeln(princ);
end.
----------------- CUT HERE ----------------------------
The result follows :
bug.bin
0
1
!!!
Has anyone an idea about that ?
-------------------------------------------------------------------------------|
bonnetf@apo.esiee.fr | |
coupriem@apo.esiee.fr (he found the bug !) |
| Surfing ... |
E.S.I.E.E | |
BP99 93162 Noisy le Grand cedex.FRANCE. | the rest is details ! |
Fax : 33 1 45 92 66 99 | |
-------------------------------------------------------------------------------|rehrauer@apollo.HP.COM (Steve Rehrauer) (10/16/90)
In article <9010151553.AB00336@apo.esiee.fr> bonnetf@apo.esiee.fr (bonnet-franck) writes: >We found a strange bug in pascal compiler (Pascal compiler 68K Rev 8.7(271)) >The source program follows : >----------------- CUT HERE ---------------------------- >program b(input, output); >var princ: integer; >procedure p(var s:integer); >begin > s := 1; > writeln(s); >end; > >begin >p(princ); >writeln(princ); >end. >----------------- CUT HERE ---------------------------- >The result follows : >bug.bin > 0 > 1 Sigh. You've uncovered a cute little hole in our Pascal. Do you really want to know why it fails? I thought not. :-) The semi-good news is that if you [a] compile at -opt 1, or [b] change your declarations from integer to integer32, things will work. The bad news is that I've verified that this bug is still in 8.8 Pascal, which is currently in advanced throes of Beta testing. The ugly news is that a fix for it won't get into the first release of 8.8. Sigh, if only you'dve noticed it a few weeks ago... I've logged it in our internal bug reports; I suggest you APR it as well, so you can track it. If we do a patch release of 8.8, the fix may get in that, especially if you really need it fixed and scream loudly enough. Apologies. -- "I feel lightheaded, Sam. I think my | (Steve) rehrauer@apollo.hp.com brain is out of air. But it's kind of | The Apollo Systems Division of a neat feeling..." -- Freelance Police | Hewlett-Packard
jal@acc (John Lauro) (10/16/90)
In article <9010151553.AB00336@apo.esiee.fr> bonnetf@apo.esiee.fr (bonnet-franck) writes: >The result follows : > >bug.bin > 0 > 1 > >!!! >Has anyone an idea about that ? > Ouch! That's a nasty bug! I just tested it, and the bug appears on the 10000 too. I was able to remove the bug by compiling with: pas bug -opt 1 (or -opt 0, which is no optimization. The default is full or 4). - John_Lauro@ub.cc.umich.edu
krowitz@RICHTER.MIT.EDU (David Krowitz) (10/16/90)
Here are my results from a DN3000 running SR10.2 (Pascal 8.7)
$ pas bug.pas -opt 0
No errors, no warnings, no info msgs, Pascal compiler 68K Rev 8.7(271)
$ bug.bin
1
1
$ pas bug.pas -opt 1
No errors, no warnings, no info msgs, Pascal compiler 68K Rev 8.7(271)
$ bug.bin
1
1
$ pas bug.pas -opt 2
No errors, no warnings, no info msgs, Pascal compiler 68K Rev 8.7(271)
$ bug.bin
0
1
$ pas bug.pas -opt 3
No errors, no warnings, no info msgs, Pascal compiler 68K Rev 8.7(271)
$ bug.bin
0
1
$ pas bug.pas -opt 4
No errors, no warnings, no info msgs, Pascal compiler 68K Rev 8.7(271)
$ bug.bin
0
1
Moral of the story:
There appears to be a bug in the Pascal optimizer (what else is new?) for
optimization levels 2, 3, and 4. I believe that the default optimization
level for all Apollo compilers used in the Aegis environment is opt level 3.
-- David Krowitz
krowitz@richter.mit.edu (18.83.0.109)
krowitz%richter.mit.edu@eddie.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)rehrauer@apollo.HP.COM (Steve Rehrauer) (10/16/90)
In article <1990Oct15.194259.7815@engin.umich.edu> jal@acc (John Lauro) writes: >In article <9010151553.AB00336@apo.esiee.fr> bonnetf@apo.esiee.fr (bonnet-franck) writes: >>The result follows : >> >>bug.bin >> 0 >> 1 >> >>!!! >>Has anyone an idea about that ? >> > >Ouch! That's a nasty bug! Yes, it is. Sigh. >I just tested it, and the bug appears on the 10000 too. >I was able to remove the bug by compiling with: > pas bug -opt 1 >(or -opt 0, which is no optimization. The default is full or 4). Well, actually the default is 3. -opt 4 turns on procedure-inlining and relaxes some FORTRAN aliasing constraints, among other things. (And, I should mention that although -opt 0 turns off "high-level" global optimizations, there's still some instruction-level optimization happening. If you really-by-gosh want the compilers to dork with your code as little as possible, say -dba. That disables durn near everything, and is guaranteed to produce Real Dumb code.) -- "I feel lightheaded, Sam. I think my | (Steve) rehrauer@apollo.hp.com brain is out of air. But it's kind of | The Apollo Systems Division of a neat feeling..." -- Freelance Police | Hewlett-Packard
buchs@MAYO.EDU (Kevin J. Buchs) (10/16/90)
Did you try different optimization levels? A faulty optimization could have reversed the writeln and assignment. ------------------------------------------------------------- Kevin Buchs Internet: buchs@mayo.edu Mayo Foundation Is this my life or is it just an Rochester, MN 55905 incredible, high-speed, simulation? (507) 284-0009 -S. R. Cleaves -------------------------------------------------------------
krowitz@richter.mit.edu (David Krowitz) (10/16/90)
I have wasted hours and hours of my employer's time fiddling with C and Pascal code and then looking at the psuedo-assember listing produced with the -exp switch in order to get the compilers to produce "Real Smart code" (ie. efficient code). Things like trying to convince the compiler that once a pointer has been loaded into an address register, it does not have to be reloaded on each pass of the loop. On the other hand, I've gotten *real* good at finding compiler errors by just looking at the psuedo-assembler ... when, oh, when, is HP/Apollo going to release a real assembler so we can hand code our program kernals the way we want them? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter.mit.edu@eddie.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
derstad@cim-vax.honeywell.com ("DAVE ERSTAD") (10/16/90)
Well, I replicated the bug. The only bright side is that it appears to be in the optimizer, not the compiler front-end. If you disable optimization, the problem goes away. On the not-so-bright side, the problem exists in the PRISM compiler as well, which kind of suprised me. I'd like to know what you here from HPApollo, and in particularly hear what specific configurations of code are likely to cause problems. Dave Erstad Honeywell SSEC DERSTAD@cim-vax.honeywell.com