http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56094
--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-28 08:55:55 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. > > 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. This patch looks like a good way forward to me (moving the input_location logic to the single caller of expand_all_functions () would be even better of course, at best up to finalize_compilation_unit - which also should not need to save the old location but simply arrange it to be UNKNOWN_LOCATION. That we need input_location during RTL expansion (and RTL opts even?) is of course bad enough :/) I'm not sure we want this kind of patch for stage4 though, eventually we should simply go with setting input_location to UNKNOWN inside force_gimple_operand and friends.
