This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc compile-time performance
- From: Akim Demaille <akim at epita dot fr>
- To: dewar at gnat dot com (Robert Dewar)
- Cc: haberg at matematik dot su dot se, gcc at gcc dot gnu dot org, help-bison at gnu dot org, Paul Hilfinger <Hilfinger at cs dot berkeley dot edu>
- Date: 20 May 2002 20:22:24 +0200
- Subject: Re: gcc compile-time performance
- References: <20020520163824.457B2F28C4@nile.gnat.com>
>>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:
>> 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.
Robert> I know that theory, but in practice we find that in the GNAT
Robert> world, where error messages are good, and the compiler very
Robert> rarely gets derailed, people want to see as much as posisble
Robert> in a single run.
I feel I should cite Paul Hilfinger here, and cc to him.
--------------------------------------------------
To be honest, however bad panic-mode syntactic error recovery might be
in Bison, in practice it doesn't seem so terrible *given how it is now
used.* Back in the good old days when I had to wait quite a while
for a compilation, good error recovery was extremely useful, since it
allowed me to get more errors per run, and therefore significantly
affected productivity. The way I work now, and with the speed of
modern computers, the "compile to the first syntax error, fix, and repeat"
technique has become increasingly viable over the years. That's why I
must admit that it's not easy for me to get terribly excited over
major innovation in this area, and I've just been looking to clean up
a few fringes.
If you do want to implement your idea or something more ambitious, do
be sure to check the literature (Corbett's dissertation has quite a
few pointers, plus caveats about some of the apparently attractive
techniques). It's surprising what can and has been done in this area.
One of my favorites: GNU Ada (GNAT) allows forward declarations of
nested subprograms, which look like this
...
procedure Glorp (X: Integer);
and full subprogram definitions of these nested subprograms, like this:
...
procedure Glorp (X: Integer) is -- YYY
Local_Var: Integer;
begin
...
end;
-- XXX
A common error is to write ";" instead of "is" on line -- YYY. It
then LOOKS like a forward declaration followed by more variable
definitions, followed by the body of the surrounding package or
subprogram. The compiler does not discover a problem until it finds
that -- XXX is not the end of the file. The GNAT compiler actually
reports this error by saying that you wrote ";" rather than "is" on
line YYY, even though the syntax error isn't detected until line
-- XXX. There are automatic techniques that can perform feats like
this---pretty neat.
Paul Hilfinger