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. Then in tree-eh, you would similarly only set the location of gimple stmts that have UNKNOWN_LOCATION. r~