This is the mail archive of the
mailing list for the GCC project.
Re: gcc compile-time performance
- From: dewar at gnat dot com (Robert Dewar)
- To: dewar at gnat dot com, haberg at matematik dot su dot se
- Cc: gcc at gcc dot gnu dot org, help-bison at gnu dot org
- Date: Mon, 20 May 2002 12:38:24 -0400 (EDT)
- Subject: Re: gcc compile-time performance
> As noted by Paul Hilfinger in the Bug Bison list, widespread access to
> interactive computing makes it more prudent with a "compile to the first
> syntax error, fix, and repeat" approach.
I know that theory, but in practice we find that in the GNAT world, where
error messages are good, and the compiler very rarely gets derailed, people
want to see as much as posisble in a single run.
A lot depends on the behavior of the compiler. I certainly agree with this
philosophy when I am using GNU C, because I find it often the case that
you get piles of error messages.
> lso, modern languages (like say C++) making use of lot of context
> information, which are better for humans, are difficult for computers to
> make sensible error recovery: Typically some semantic information (like a
> declaration) is lost, and the rest of the compile becomes unrecoverable and
> nonsensical. That is, unless one is trying to capture that semantic
> information, which is a computer language current research topic.
Compilers can do MUCH better than people think. You need to hear my talk
on this subject some time :-) Indeed the GNAT front end is intended as a
demonstration of just what can be done in understanding.
As an example, if you see an end or } that is malformed or unexpected, then
it is quite important to try to figure out the structure. This is much harder
in C++ than in Ada, but not impossible. It is a place where looking at the
indentation of the source is a very valuable clue in doing repairs. In
general GNAT pays quite a bit of attention to layout
a := b C;
a :- b
A lot of people are used to the kind of error messages that come from fairly
naive bottom up automatic parsers like YACC. You can do a *LOT* better than
this if you take the effort.
Yes, sometimes a compiler will fall down, but it is amazing how well you
can do by using specialized techniques that address specific problem areas
in a language. I don't know the C++ grammar as well as I know the Ada
grammar, but from what I know there are things that are easier and things
that are harder (as an example of something really hard in Ada, consider
the issue of IS vs semicolons in bodies vs specs, a very common cut and
paste error that all other Ada compilers than GNAT completely fall down on.
There is very specialized circuitry in GNAT to handle this specific case.