On Tue, Nov 27, 2012 at 3:54 PM, Dehao Chen <de...@google.com> wrote: > On Tue, Nov 27, 2012 at 1:46 AM, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Mon, Nov 26, 2012 at 11:54 PM, Dehao Chen <de...@google.com> wrote: >>> The new patch is attached. Bootstrapped and passed gcc regression test. >>> >>> Ok for trunk? >> >> Hmm ... this merely avoids some UNKNOWN_LOCATIONs which should >> be ok. I think the issue is that gimplify_expr does: >> >> saved_location = input_location; >> if (save_expr != error_mark_node >> && EXPR_HAS_LOCATION (*expr_p)) >> input_location = EXPR_LOCATION (*expr_p); >> >> thus it retains input_location from previous recursive invocations (that's >> ok). >> >> But it doesn't seem to be the case that input_location is UNKNOWN_LOCATION >> during GIMPLE passes (which it really should be ...). So to fix the >> gimplification >> issue I think that gimplify_ctx should have a location (initialized to >> UNKNOWN_LOCATION), which it saves/restores across its push/pop >> operation. >> >> Or of course that inside the pass manager before executing passes assert >> that input_location is UNKNOWN_LOCATION and fix up things according >> to that. First offender is in cgraphunit.c in cgraph_analyze_function: >> >> location_t saved_loc = input_location; >> input_location = DECL_SOURCE_LOCATION (decl); >> >> that should be totally unnecessary (input_location shoud be and stay >> UNKNOWN_LOCATION). And finalize_compilation_unit (the last thing >> the frontends should call) should have input_location = UNKNOWN_LOCATION >> right at the point it clears current_function_decl / cfun. >> >> I'd prefer the 2nd approach (maybe without the assert as we are in stage3 >> already, but the assert would certainly help). And places in the middle-end >> that set input_location for purpose of (re-)gimplifying should use the >> location >> in the gimplify ctx (which would need to be added) instead of setting >> input_location. >> >> Maybe as a first try set input_location to UNKNOWN_LOCATION in >> finalize_compilation_unit. >> >> Thanks, >> Richard. > > Shall we check in this patch first, and have another patch to reset > input_location?
Sure, that works for me. It might be harder for you to verify that doing that also fixes the issue though ;) Richard. > Thanks, > Dehao
