The problem is that linemap_location_from_macro_expansion_p will always return true if locus has discriminator. And in linemap_lookup, this will lead to call linemap_macro_map_lookup, in which there is an assertion:
linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set)); However, line is actually not a macro location. Dehao On Tue, May 13, 2014 at 9:47 AM, Cary Coutant <ccout...@google.com> wrote: >> Index: gcc/input.c >> =================================================================== >> --- gcc/input.c (revision 210338) >> +++ gcc/input.c (working copy) >> @@ -910,6 +910,8 @@ location_with_discriminator (location_t locus, int >> : next_discriminator_location); >> >> next_discriminator_location++; >> + if (next_discriminator_location > line_table->highest_location) >> + line_table->highest_location = next_discriminator_location; >> return ret; >> } > > It seems to me that if something is breaking because highest_location > isn't getting updated, there's a deeper problem. The discriminator > handling depends on the fact that the line table doesn't ever add any > new values after min_discriminator_location is set, and the routines > in libcpp shouldn't ever see a location_t value above > min_discriminator_location (it should be converted to a "real" > location_t via map_discriminator_location()). If libcpp now assigns > new location_t values after we start handing out discriminators, then > we'll probably need to have libcpp start handling discriminator values > (which is the solution for LTO as well). If you're just seeing leakage > of discriminator locations into libcpp, there's probably a spot where > we need to call map_discriminator_location(). > > -cary
