Fix ICE in substring-handling building 502.gcc_r (PR 87562)
authorDavid Malcolm <dmalcolm@redhat.com>
Thu, 18 Oct 2018 15:44:39 +0000 (15:44 +0000)
committerDavid Malcolm <dmalcolm@gcc.gnu.org>
Thu, 18 Oct 2018 15:44:39 +0000 (15:44 +0000)
commit05d57d6561dc3c10cd777a5c783833b2c2e37074
tree74166f3b076288dd91cda5512c9cdc8f9a4158e5
parentfab2c75b73c11d5c6d652a20bfa34e1733f1407f
Fix ICE in substring-handling building 502.gcc_r (PR 87562)

In r264887 I broke the build of 502.gcc_r due to an ICE.
The ICE occurs when generating a location for an sprintf warning within
a string literal, where the sprintf call is in a macro.

The root cause is a bug in the original commit of substring locations
(r239175).  get_substring_ranges_for_loc has code to handle the case
where the string literal is in a very long source line that exceeds the
length that the current linemap can represent: the start of the token
is in one line map, but then another line map is started, and the end
of the token is in the new linemap.  get_substring_ranges_for_loc handles
this by using the linemap of the end-point when building location_t
values within the string.  When extracting the linemap for the endpoint
in r239175 I erroneously used LRK_MACRO_EXPANSION_POINT, which should
have instead been LRK_SPELLING_LOCATION.

I believe this bug was dormant due to rejecting macro locations earlier
in the function, but in r264887 I allowed some macro locations in order
to deal with locations coming from the C++ lexer, and this uncovered
the bug: if a string literal was defined in a macro, locations within
the string literal would be looked up using the linemap of the expansion
point of the macro, rather than of the spelling point.  This would lead
to garbage location_t values, and, depending on the precise line numbers
of the two locations, an assertion failure (which was causing the build
failure in 502.gcc_r).

This patch fixes the bug by using LRK_SPELLING_LOCATION, and adds some
bulletproofing to the "two linemaps" case.

Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu
(g++.sum gained 5 PASS results; gcc.sum gained 3 PASS results).
I also verified that this fixes the build of 502.gcc_r.

gcc/ChangeLog:
PR tree-optimization/87562
* input.c (get_substring_ranges_for_loc): Use
LRK_SPELLING_LOCATION rather than LRK_MACRO_EXPANSION_POINT when
getting the linemap for the endpoint.  Verify that it's either
in the same linemap as the start point's spelling location, or
at least in the same file.

gcc/testsuite/ChangeLog:
PR tree-optimization/87562
* c-c++-common/substring-location-PR-87562-1-a.h: New file.
* c-c++-common/substring-location-PR-87562-1-b.h: New file.
* c-c++-common/substring-location-PR-87562-1.c: New test.
* gcc.dg/plugin/diagnostic-test-string-literals-1.c: Add test for
PR 87562.
* gcc.dg/plugin/pr87562-a.h: New file.
* gcc.dg/plugin/pr87562-b.h: New file.

From-SVN: r265271
gcc/ChangeLog
gcc/input.c
gcc/testsuite/ChangeLog
gcc/testsuite/c-c++-common/substring-location-PR-87562-1-a.h [new file with mode: 0644]
gcc/testsuite/c-c++-common/substring-location-PR-87562-1-b.h [new file with mode: 0644]
gcc/testsuite/c-c++-common/substring-location-PR-87562-1.c [new file with mode: 0644]
gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
gcc/testsuite/gcc.dg/plugin/pr87562-a.h [new file with mode: 0644]
gcc/testsuite/gcc.dg/plugin/pr87562-b.h [new file with mode: 0644]