[PATCH] preprocessor: Fix ICE with too long line in fmtwarn [PR96935]

[Marek Polacek]

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