This is the mail archive of the
mailing list for the GCC project.
Re: [RFA] Fix preprocessor/6517
On Tue, May 21, 2002 at 11:40:14PM +0100, Neil Booth wrote:
> Neil Booth wrote:-
> > If the preprocessor had a fatal error during option parsing,
> > it would set its error count appropriately, but the front end
> > was ignoring it (this goes back to 3.0; stand-alone cpp0
> > was always fine). This patch causes errorcount to be set
> > in the C front ends appropriately after option processing,
> > and the compiler to exit if there are any errors after
> > option processing.
> Incidentally, Zack, this patch makes DL_FATAL almost redundant,
> a good sign IMO. All DL_FATAL are in cppinit.c, apart from
> one (recursive #include). There are only two DL_ERRORs in
> cppinit.c, which have now effectively become DL_FATAL as
> far as cc1 is concerned, which are to do with stat issues
> other than "no such directory" for include paths. Seems fine
> to me.
> I think the semantics that clients bail out if there are errors
> after processing options, and continue otherwise are sound.
> Apart from polling, there is no easy way for a client to know
> whether a fatal error has occured (recursive #include is all
> that remains anyway).
Excessive #include nesting really shouldn't have been a fatal error in
the first place -- the important bit is that a potential infinite loop
gets aborted. Which we already do by not calling _cpp_execute_include
in that case.
I'd suggest making the DL_FATAL instances in sanity_checks() into
DL_ICE instead of DL_ERROR. The "I/O error on output" message, and
the inconsistent options messages, make sense as DL_ERROR.