This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Plan for removing global state from GCC's internals
- From: David Malcolm <dmalcolm at redhat dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 02 Jul 2013 11:26:51 -0400
- Subject: Re: Plan for removing global state from GCC's internals
- References: <1372272382 dot 1022 dot 26 dot camel at surprise> <Pine dot LNX dot 4 dot 64 dot 1306262002150 dot 30407 at digraph dot polyomino dot org dot uk> <1372295735 dot 1022 dot 72 dot camel at surprise> <Pine dot LNX dot 4 dot 64 dot 1306271425010 dot 4602 at digraph dot polyomino dot org dot uk> <1372360959 dot 1789 dot 32 dot camel at surprise> <Pine dot LNX dot 4 dot 64 dot 1306271933460 dot 10184 at digraph dot polyomino dot org dot uk> <1372699842 dot 1789 dot 144 dot camel at surprise> <Pine dot LNX dot 4 dot 64 dot 1307011932480 dot 13535 at digraph dot polyomino dot org dot uk>
On Mon, 2013-07-01 at 19:43 +0000, Joseph S. Myers wrote:
> On Mon, 1 Jul 2013, David Malcolm wrote:
[...]
> > Would you be in favor killing off these macros:
> > #define input_line LOCATION_LINE (input_location)
> > #define input_filename LOCATION_FILE (input_location)
> > #define in_system_header (in_system_header_at (input_location))
> > with patches that make the usage of "input_location" explicit? (by
> > replacing all uses of these macros with their expansions, cleaning up
> > line-wraps as needed).
>
> Yes.
>
> > The only other macro that implicitly uses input_location is
> > EXPR_LOC_OR_HERE; that could be removed in favor of:
> > EXPR_LOC_OR_LOC(expr, input_location)
> > again making input_location explicit.
>
> (I suspect then eliminating the input_location from this - ensuring all
> expressions have meaningful locations so EXPR_LOC_OR_LOC isn't needed at
> all - will depend on Andrew MacLeod's proposal. It doesn't explicitly
> mention this, but one thing that would be desirable as part of making
> front ends generate internal representation closer to the source would be
> explicitly representing locations for constants, and for references to
> declarations within expressions, so that everywhere that wants a location
> for an expression can reliably extract one from it rather than finding
> there is no location because certain expressions are shared.)
Thanks.
I've posted a patch for review that removes these macros:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00072.html