On Fri, Aug 10, 2012 at 12:04 PM, Richard Henderson <r...@redhat.com> wrote:
> On 2012-08-10 11:01, Dehao Chen wrote:
>> On Fri, Aug 10, 2012 at 10:52 AM, Richard Henderson <r...@redhat.com> wrote:
>>> On 2012-08-10 10:21, Dehao Chen wrote:
>>>> Yes, cxx_maybe_build_cleanup sets it to UNKNOWN_LOCATION, but during
>>>> gimplifying, it's reset to input_location:
>>>>
>>>> gimplify.c (gimplify_call_expr)
>>>> 2486 /* For reliable diagnostics during inlining, it is necessary that
>>>> 2487 every call_expr be annotated with file and line. */
>>>> 2488 if (! EXPR_HAS_LOCATION (*expr_p))
>>>> 2489 SET_EXPR_LOCATION (*expr_p, input_location);
>>>>
>>>> Shall we remove this code? Because I don't expect the location to be
>>>> unknown in other cases.
>>>
>>> Hmm. Perhaps something special-cased to TRY_FINALLY/TRY_CATCH
>>> to set input_location itself to UNKNOWN_LOCATION for the duration
>>> of gimplifying the cleanup? With a big comment about how we'll be
>>> setting unset locations for cleanups during tree-eh lowering.
>>
>> Handling TRY_FINALLY/TRY_CATCH case may not work for Java, as it also
>> shares gimplify.c
>
> For Java, the theory is that the EXPR_LOCATION of the statements in the
> catch should already be set by the front end. So the !EXPR_HAS_LOCATION
> bit there would not fire, so we'll not "reset" the location to UNKNOWN.
I see your point. But the problem is that the above code is in
gimplify_call_expr, in which we have no idea if it is in a
TRY_FINALLY/TRY_CATCH block. However, in the following code that
handles TRY_FINALLY/TRY_CATCH, the EXPR_LOCATION is already set by the
above code to input_location, thus we cannot know if it's from Java or
C++...
gimplify.c (gimplify_expr)
....
7431 case TRY_FINALLY_EXPR:
7432 case TRY_CATCH_EXPR:
7433 {
......
Thanks,
Dehao
>
> Then in tree-eh, you would similarly only set the location of gimple
> stmts that have UNKNOWN_LOCATION.
>
>
> r~
