This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: this_input_filename patch introduced bug
- From: Geoffrey Keating <geoffk at apple dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 30 Jul 2003 13:57:28 -0700
- Subject: Re: this_input_filename patch introduced bug
On Wednesday, July 30, 2003, at 10:50 AM, Per Bothner wrote:
Geoffrey Keating wrote:
I think it'll be OK. I'm not sure that a "main input filename" is
such a useful concept any more; if it's a problem that
main_input_filename doesn't match in_fnames[0], it's likely a problem
that it doesn't match in_fnames[1] too.
In my compile server code, I set main_input_filename to (the
equivalent) of in_fnames[i] for the current i. I.e. it replaces the
new this_input_filename. We may need in_fnames[0] before we start
processing the input files (e.g. for some debugging formats), but once
i>0 it is probably more useful to have main_input_filename be
in_fnames[i] rather than in_fnames[0].
Most places that look at main_input_filename do it exactly once per
compilation, so I don't know what this buys you except further
inconsistency: some places will look at it at the start of compilation
and get in_fnames[0], and other places will look at the end of
compilation and get in_fnames[n-1].
--
Geoff Keating <geoffk@apple.com>