On Wed, Sep 16, 2020 at 03:15:19PM -0400, David Malcolm via Gcc-patches wrote: > 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
Thanks for the quick review, pushed with the "zero start column" change. Marek
