Re: cpplib startup patch

[craig@jcb-sc.com]

>Jason Merrill wrote:
>
>> The problem is that without the patch, cpplib unconditionally inserts a
>> #line directive at the beginning of the file (# 1 "wa.ii"), so the frontend
>> sees that one instead, and thinks wa.ii is the main filename.
>
>I just did some more testing and found that the non-cpplib version of cpp also
>does this. Is this really a bug after all?

I don't *think* so, though it's been well over a year since I looked into
this.  (Maybe two!)

Back then, I made some pretty non-trivial mods to g77 to ensure that,
if the first line of the input *was* `# 1 "filename"', that filename
got recorded as the main filename, *before* the yyparse() function was
called by toplev.

I think this was because there were some things that toplev did (or called)
before yyparse() that might produce diagnostics.  Those diagnostics
weren't looking "right" for g77 using preprocessed input.

Or, maybe it was because some diagnostics, emitted even *after* the
call to yyparse() started, used the main filename in their printouts.

So g77 has one of its pre-yyparse() routines (called by toplev) go ahead
and start parsing the file, far enough to see if the first line is
"special", to set the main filename if so, otherwise leaving enough
info around so yyparse() (g77's lex.c, ultimately) can re-parse the
first line as part of normal parsing.

In any case, it's entirely possible the need for this kludge has since
disappeared, in which case it'd be great to know that, so we could
rip it out of g77.

If you look into this a bit and realize I'm not entirely wrong (about
the present state of gcc, at least) about the need for the kludge,
but need more info or, say, an example of what the failure looked
like, let me know, and I'll conduct a search of the relevant documents,
archives, etc. pertaining to g77's history.

        tq vm, (burley)