On Wed, 2020-09-16 at 11:16 -0400, Marek Polacek wrote: > Here we ICE in char_span::subspan because the offset it gets is -1. > It's -1 because get_substring_ranges_for_loc gets a location whose > column was 0. That only happens in testcases like the attached where > we're dealing with extremely long lines (at least 4065 chars it > seems). > This does happen in practice, though, so it's not just a theoretical > problem (e.g. when building the SU2 suite). > > Fixed by checking that the column get_substring_ranges_for_loc gets > is > sane, akin to other checks in that function. > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?
[...] Thanks for the patch. > index d573b90341a..ea3d4f34220 100644 > --- a/gcc/input.c > +++ b/gcc/input.c > @@ -1461,6 +1461,8 @@ get_substring_ranges_for_loc (cpp_reader > *pfile, > size_t literal_length = finish.column - start.column + 1; > > /* Ensure that we don't crash if we got the wrong > location. */ > + if (start.column < 1) > + return "line is too long"; Nit: I believe this could also happen for very large source files when locations exceed LINE_MAP_MAX_LOCATION_WITH_COLS. So the error message should read "zero start column", or even just "start.column < 1" I think. (if we have a negative column number then something has gone badly wrong; not sure if that's expressible via #line directives) OK with that change. Dave > if (line.length () < (start.column - 1 + literal_length)) > return "line is not wide enough"; > [...]
