http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #13 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-01-25 11:43:37 UTC --- (In reply to comment #12) > Created attachment 29272 [details] > gcc48-pr56094.patch > > input_location is used heavily in the gimplifier, gimplify_expr sets it from > the expression being currently gimplified (if it has any), and for temporaries > and their initializers that are created while gimplifying that stmt it is > intentional to use the location of that expression. 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. Moreover, if gimplifying occurs after parsing is completed, why do we need to use input_location as a communication device between parts of the gimplifier, why not just use some gimplifier-specific state or pass down specific locations. > I've bootstrapped/regtested this patch on i686-linux (no ada) so far, the > lex.c > hunk is to avoid ICEs when e.g. tree-parloops.c calls the make_type langhook > (but there are other callers of that) with input_location of UNKNOWN_LOCATION. > I was surprised there weren't regressions, given that input_location is used > implicitly e.g. by all error/warning calls, unless they supply their own > location. 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).
