[PATCH] c-ppoutput: Fix preprocessing ICE on very large line number [PR99325]

Nathan Sidwell nathan@acm.org
Thu Mar 4 12:55:43 GMT 2021


On 3/4/21 4:03 AM, Jakub Jelinek wrote:
> Hi!
> 
> In libcpp, lines are represented as linenum_type, which is unsigned int.
> The following testcases ICE because maybe_print_line_1 is sometimes called
> with UNKNOWN_LOCATION (e.g. at pragma eof) and while most of the time
> the
>         && src_line >= print.src_line
>         && src_line < print.src_line + 8
> check doesn't succeed for the src_line of 0 from UNKNOWN_LOCATION, when
> print.src_line is from very large line numbers (UINT_MAX - 7 and above)
> it succeeds (with UB on the compiler side) but src_file is NULL for
> UNKNOWN_LOCATION and so the strcmp call ICEs.
> As print.src_line can easily wrap around, this patch changes its type
> to unsigned int to match libcpp, so that we don't invoke UB in the compiler.
> For print.src_line of UINT_MAX - 7 and above, src_line from UNKNOWN_LOCATION
> will not pass that test anymore, but when it wraps around to 0, it can,
> so I've also added a check for src_loc != UNKNOWN_LOCATION (or, if
> preferred, could be src_file != NULL).
> Besides fixing the ICE and UB in the compiler, I believe worst case the
> patch will cause printing a few more line directives in the preprocessed
> source around the wrapping from lines UINT_MAX - 7 to 0 (but less
> around the wrapping from INT_MAX to INT_MAX + 1U), but I think those
> are exceptional cases (sources with > 2billion lines are rare and
> we warn or error on #line > INT_MAX).
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2021-03-03  Jakub Jelinek  <jakub@redhat.com>
> 
> 	PR c/99325
> 	* c-ppoutput.c (print): Change src_line type from int to unsigned.
> 	(token_streamer::stream) Likewise.
> 	(maybe_print_line_1): Likewise.  Don't strcmp src_file if src_loc is
> 	UNKNOWN_LOCATION.

ok.  thanks!
I think I noticed that signed/unsigned confusion when futzing around 
with modules, but didn't feel like diving in :)

nathan

-- 
Nathan Sidwell


More information about the Gcc-patches mailing list