This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc compile-time performance


>>>>> "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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]