joemu@tekecs.UUCP (10/30/84)
Don Seely (sp?) asked a while back for some "programs" that will cause PCC
to core dump. He originally stated that he wanted to start a contest to find
the shortest program that would core dump the compiler.
What I would ask is that we forget about this type of "contest" and
concentrate on finding and fixing bugs. I applaud Don's activities on the
f77 compiler and would be more than happy to see him set up something
similar to it for pcc. I would like to see all types of bugs reported,
not just "core dumpers".
Here are a couple bugs that come to mind.
------------------------------------------------------------------------
This causes cpp to core dump on many systems:
#if 1/0
#endif
------------------------------------------------------------------------
This causes ccom to die on many systems:
char foo[-1]; /* the -1 turns into a huge number */
------------------------------------------------------------------------
This causes ccom to generate bogus instructions on the vax:
float foo; /* double works just as well */
foo++; /* the infamous incf instruction */
foo--; /* the infamous decf instruction */
predecrement and preincrement work just as well.
------------------------------------------------------------------------
The scope of typedef's is screwed on most systems:
Typedefs should behave as ordinary identifiers (i.e. they can be
redeclared in inner blocks). Most compilers handle typedefs as
global identifiers independent of scoping rules. Try the fragment of
code from K&R pp. 206
typedef float distance;
...
{
auto int distance;
...
This generates a syntax error on many implementations.
------------------------------------------------------------------------
I hope this gets us off to a better start. Keep up the great work
Don!
Joe Mueller
UUCP: ...!{ucbvax or decvax}!tektronix!tekecs!joemu
ARPA: tekecs!joemu.tektronix @ udel-relaygwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (11/02/84)
> What I would ask is that we forget about this type of "contest" and > concentrate on finding and fixing bugs. I applaud Don's activities on the > f77 compiler and would be more than happy to see him set up something > similar to it for pcc. I would like to see all types of bugs reported, > not just "core dumpers". Right, let's try to fix PCC bugs. It would be a pity to start with the UNIX/32V or USG 3.0 PCC (whatever it is that 4.2BSD comes with), since I have found that later releases of PCC have had major portions rewritten to fix bugs. Starting with the latest release would seem to be the most productive approach. Speaking of which, can anyone predict whether PCC2 is going to supplant PCC in the near future? Last I heard, it was considerably slower than PCC so maybe PCC will be around for a while.
chris@umcp-cs.UUCP (Chris Torek) (11/03/84)
* This causes ccom to generate bogus instructions on the vax:
float foo; /* double works just as well */
foo++; /* the infamous incf instruction */
foo--; /* the infamous decf instruction */
Which Vax? The 4.2BSD PCC does the ``right thing'' (generates an
addd2 instruction, with lots of conversions; ugly, but effective).
--
(This mind accidently left blank.)
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandado@elsie.UUCP (Arthur David Olson) (11/03/84)
brl-tgr!gwyn: > Right, let's try to fix PCC bugs. It would be a pity to start with the > UNIX/32V or USG 3.0 PCC (whatever it is that 4.2BSD comes with), since > I have found that later releases of PCC have had major portions > rewritten to fix bugs. Starting with the latest release would seem to > be the most productive approach. Actually, starting with code that's not a trade secret would seem to be the most productive approach. . .you could then post it to the network and give everyone the benefit of your work. -- ..decvax!seismo!elsie!ado (301) 496-5688 DEC, VAX and Elsie are Digital Equipment and Borden trademarks