[RFC] Fix for PR58201

Jan Hubicka hubicka@ucw.cz
Sun Sep 8 00:34:00 GMT 2013


> > Hi all, Jakub,
> > 
> > On 09/07/2013 01:16 PM, Jakub Jelinek wrote:
> > >As I wrote in the PR, IMHO mangle_decl should
> > >   location_t save_location = input_location;
> > >   input_location = DECL_SOURCE_LOCATION (decl);
> > >...
> > >   input_location = save_location;
> > >around the call,
> > I had a look and I'm afraid this is already happening and isn't
> > enough: in mangle_decl_string, the call of write_mangled_name is
> > wrapped in exactly what you are suggesting. Or you mean something
> > else?
> > 
> > Otherwise, I'm afraid we have to resort to what Jason too appears to
> > find acceptable, thus what Honza proposed about UNKNOWN_LOCATION +
> > the tweak to print_instantiation_partial_context_line (essentially
> > just return immediately if loc == UNKNOWN_LOCATION, I think)
> 
> Yes, I think those two changes makes perfect case.  Middle end probably should
> be more consistent about not setting input_locations beyhond of this point (it
> does not really make much sense).  It is not how things works unforutnately -
> RTL expansion still lives in statement at a time and uses input location to 
> propagate things down and there are many other random setters of this variable.
> 
> I will try to audit things incrementally.  With the change to cgraphunit I made
> this week all mangling ought to happen early (this is also not 100% true: in
> some very special cases where we late access virtual tables through BINFOs, I
> have independent fix for that).

Also I think with David's changes to get rid of global contextes, we probably should
have universum (w/o any location), function (with start/end locations as we have in cfun
now) and expression (with its own location) contextes now.

It would map to our global state, cfun+current_function_decl and
input_location+rtl_profile_for_bb in our current state of things.

Diagnostic than should know if it binds to specific function or specific statement
and can pick the porper location.

Honza
> 
> Honza
> > 
> > Paolo.



More information about the Gcc-patches mailing list