This is the mail archive of the gcc-bugs@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]

[Bug tree-optimization/56094] Invalid line number info generated with tree-level ivopts


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.


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