phil@DECWRL.DEC.COM (Phil Hochstetler) (07/18/89)
Version of GNU CC: gcc version 1.35
Input file:
/* GNU C compiler fails to flag the type mismatch between enums */
main()
{
enum option { oHEAD, oMIDDLE, oTAIL};
enum again {one, two, three};
enum option try2;
enum again try3;
try2 = oTAIL;
try3 = three;
if (try2 == try3) /* compiler should complain */
exit(1);
}
Compiled via: gcc -g -o foo foo.c
tm.h and md file: md -> config/i386.md
tm.h -> config/tm-seq386.h
type of machine: Sequent SYMMETRY
OS name and version: DYNIX(R) V3.0.15
Bad behavior: Should complain about enum type mismatch, but does not.guccione@SRC.HONEYWELL.COM (Steve Guccione) (08/07/89)
I am sending in a bug report for a somewhat small problem I have
encountered in installing Gnu C. I am attempting to put the compiler
on the System resourse Manager (SRM) for an Intel iPSC/2 Hypercube.
This SRM is actually an Intel 386 machine running Unix System V (or at
least what they claim is System V). The default C compiler in Green
Hills C. When installing gcc, the green Hills compiler barfed on a
ELSE statement in the READER.C file on line 269.
After some testing it seems that the Green Hills compiler cannot
handle the comment directly following the "else". Adding a space
between the two seems to fix the problem.
I realize that this is not exactly your problem, but rather one with
the Green Hills C (which is another good reason to use Gnu C!). But
if you could addaspace before the comment in the next release, it may
save some other poor engineer / system administrator from trying to
figure this out. (Note: It is not obvious that placement of a comment
would give the strange error messages received).
On a personal note, thanks much for the work you are doing. It is
good to see some high quality software has been made available in this
fashion. I have recommended that our research center, and Honeywell
support Gnu, and I believe this is happening. I hope one day I will
be able to make a more personal contribution to you effort.
Thanks Again.
-- Steve
-- 8/6/89
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Steve Guccione
Honeywell Systems and Research Center
MAIL: 3660 Technology Dr. Minneapolis, MN 55413
PHONE: (612) 782-7311
ARPA: guccione@src.honeywell.com
UUCP: {umn-cs, ems, bthpyd}!srcsip!guccione
---------- "Bug" follows: ------------------------
Simple example of source code:
#include <stdio.h>
main ()
{
int c=1;
if (c == 1)
printf("c is 1.\n");
else/* This is a comment */
printf("c is 2.\n");
}
Response of the Green Hills C-386:
C-386 1.8.4b Copyright (C) 1983,1984,1985,1986,1987,1988 Green Hills Software, Inc. All rights reserved.
"test.c", line 11: Undefined symbol: else
"test.c", line 11: expected: ';' got: namegrunwald@flute.cs.uiuc.edu (Dirk Grunwald) (08/07/89)
We have installed `gcc' on the same configuration (iPSC/2 SRM). If we need to compile from scratch, e.g. if the previous version of `gcc' was buggy or when we installed it first time, we compile everything possible using `cc' (i.e. the greenhills compiler). When that finally died, we compiled the remaining files using `pcc', the portable C compiler. Between the two, they manage to compile everything (eventually). Eventually, we decided to bag it & use cross compilation on an Encore Multimax; the multimax compiles the code to .s files, which are shipped to the SRM and assembled (*sigh* would it be that gas had COFF support). Although the SRM has a reasonable CPU, it is incredibly I/O bound; for some programs (e.g. the inner loop of a parallel prolog byte interpreter that was all one switch statement), the greenhills compiler thrashed the system to death & eventually reported that the routine was too big. Gnu C (on the Encore) managed to compile it, although it *did* take about 20Mb of swap to do it. Thank you FSF.
ewerlid@MIZAR.DOCS.UU.SE (Ove Ewerlid) (08/07/89)
In a recent posting to bug-gcc Dirk Grunwald writes: > some programs (e.g. the inner loop of a parallel prolog byte > interpreter that was all one switch statement), the greenhills > Gnu C (on the Encore) managed to compile it, although it *did* take > about 20Mb of swap to do it. I ran into the same problem when I compiled straight-line-coded DFA:s. One particular program contained approx 1000 switches and 60000 cases. Investigating the problem it turned out that every case consumed quite some amount of memory due to the fact that every case was treated as a label. ie: case 1: case 2: case 3: case 4: action will produce 4 labels in the parsing phase. No lookahead is done to determine that the above is a range. It could be done by a right associative rule in the parsing grammar. I did not do that :-( Instead I did it in a hackish way: ie: case 1: goto action case 2: goto action case 3: goto action case 4: goto action which is the redundant output generated by the DFA-converter. This is easier to parse (a simple rule addition) and connect to the C backend (simply do not create a unique case label, give it the action label instead). So, while the source is bigger the VM consumption is much lower. The program above compiled with a mere 9Mb of VM instead of an unknown amount of 24Mb+. (The program itself was 2Mb, one function) The (ideal?) solution is to hack the parsing grammar according to the first of the above hacks. Fortunately the design of GCC is a very clean ditto and hacks of the above character is quite easy to do. Still it always takes time........ Your problem may ofcourse not be due to a very large percentage of cases in one function. The machine you are using may be a real VM killer or your switch may contain large chunks of solid code etc. Sorry, folks, to mention a solution to a problem without a patch. (To be fair, I must say that the sun4-cc eventually aborted with a bunch of bogus warnings when compiling the above 2Mb program! Question: How far away was the bug fix?) Ove