This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Add extra location information - PR43486


> >> and at that point you have lost your extra location
> >> information.
> >
> > Actually no, see the c-family/c-common.c patch, copied here, which
> > ensures that folding does preserve such information:
> 
> Thanks.  I think I would like some clarity on when the extra location
> information is available.

Typically the extra information would be used right before gimplification,
just after the front-end has done its job (e.g. via the PLUGIN_PRE_GENERICIZE
hooks if implemented via a plug-in). It could also be used during the
front-end itself, to e.g. generate more accurate error messages or warnings.

> For better or for worse the C frontend does
> sometimes call directly into fold-const, without going through
> c_fully_fold.

Ah yes... I can't resist but note the following comment in fold_convert_loc:
--
Used by the middle-end for
simple conversions in preference to calling the front-end's convert.
--

Not only used by the middle-end apparently... So I guess we should first
clarify whether this is an API/layering violation.

> E.g., I see calls to fold_convert and fold_build2_loc.
> What happens then?

I've looked at most of these calls in the C and C++ front-end, and I suspect
most of these calls (e.g. most calls to fold_build2_loc) correspond
to internally generated expressions, not directly relevant to the source code.

In other words, my patch aims at providing more detailed slocs
(source locations) for the source representation, so that e.g. static
analysis tools, plug-ins, diagnostic tools (potentially error messages)
have more precise source location info.

In a few cases of calls to fold_convert_loc/fold_build2_loc/etc... I guess we
might indeed loose some sloc info, to be confirmed. In which case, depending
whether e.g. calling fold_convert_loc() is indeed expected or not, we could
refine the approach to not loose this information.

Also note that we are talking about very few cases, and the idea behind the
patch is to provide extra info as much as possible, but there's always an
available fallback, which is the main source location. In other words, this
approach can be incremental, and does not need to be "complete" to become
useful.

Arno


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]