http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-01-25 
12:04:59 UTC ---
(In reply to comment #13)

> You are explaining how it works right now. What I am asking is how we want it
> to work, that is, why the gimplifier needs to care about input_location and
> cannot use *always* the location of the expression being gimplified (or some
> sub-expression) or UNKNOWN_LOCATION for things that are compiler generated.

Because not all the gimplifier routines see the current expression as whole,
they can work on some subexpression etc., and not all expressions have
location.  So, you generally want to use a location of some expression (if
known) for all the subexpressions that don't have their own location.
Currently that is performed in the gimplifier by saving the current location
in input_location variable and then lots of code use that.  Alternative to that
is use some different variable, gimplifier_location or whatever.  But you'd
really need to change lots of code for that, and I'd be afraid that some code
that needs that could be shared between FEs and the gimplifier.  E.g. make_node
uses input_location, which is desirable in the FEs, but with such a change
would be undesirable in the gimplifier.

> Does the diagnostic machinery assert that input_location != UNKNOWN_LOCATION? 
> I
> think not. I seem to remember that we sometimes generate:
> 
> warning:0:0: something
> 
> but I am not sure if this happens for warning_at(UNKNOWN_LOCATION).

E.g. for warning_at, instead of printing say:
qqq.c: In function ‘foo’:
qqq.c:4:34: warning: argument to ‘sizeof’ in ‘__builtin_memset’ call is the
same expression as the destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]
if the first argument is changed to UNKNOWN_LOCATION, it prints:
qqq.c: In function ‘foo’:
cc1: warning: argument to ‘sizeof’ in ‘__builtin_memset’ call is the same
expression as the destination; did you mean to provide an explicit length?
[-Wsizeof-pointer-memaccess]

Reply via email to