[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 --- Comment #9 from David Malcolm --- Author: dmalcolm Date: Mon Oct 29 23:58:34 2018 New Revision: 265611 URL: https://gcc.gnu.org/viewcvs?rev=265611&root=gcc&view=rev Log: Fix ICE in get_substring_ranges_for_loc on __FILE__ (PR c++/87721) PR c++/87721 reports a crash in get_substring_ranges_for_loc introduced by r265271, my fix for PR 87562. The new issue occurs when attempting to get a location with a string literal inside a macro in which the first token is __FILE__ (formed via concatenation). Attempting to get the spelling location of __FILE__ fails, leading to NULL for start_ord_map and final_ord_map, and thus a NULL pointer dereference. Given that our "on-demand" substring locations approach reparses the string literals, there isn't a good way to access the locations inside such string literals: attempting to reparse __FILE__ fails with a "missing open quote". This patch applies the easy fix by gracefully rejecting the case where the spelling locations for the start or finish give us NULL maps. gcc/ChangeLog: PR c++/87721 * input.c (get_substring_ranges_for_loc): Detect if linemap_resolve_location gives us a NULL map, and reject this case. gcc/testsuite/ChangeLog: PR c++/87721 * c-c++-common/substring-location-PR-87721.c: New test. * gcc.dg/plugin/diagnostic-test-string-literals-1.c: Add test for PR 87721. * gcc.dg/plugin/diagnostic_plugin_test_string_literals.c (test_string_literals): Fold the index arguments before checking for INTEGER_CST. Added: trunk/gcc/testsuite/c-c++-common/substring-location-PR-87721.c Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c trunk/gcc/testsuite/gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 --- Comment #8 from seurer at gcc dot gnu.org --- Build successes for intrate: 502.gcc_r(base) Build errors for intrate: None It now works with your fix, thanks!
[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from David Malcolm --- Should be fixed by r265271. Sorry for the breakage.
[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 --- Comment #6 from David Malcolm --- Author: dmalcolm Date: Thu Oct 18 15:44:39 2018 New Revision: 265271 URL: https://gcc.gnu.org/viewcvs?rev=265271&root=gcc&view=rev Log: 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. Added: trunk/gcc/testsuite/c-c++-common/substring-location-PR-87562-1-a.h trunk/gcc/testsuite/c-c++-common/substring-location-PR-87562-1-b.h trunk/gcc/testsuite/c-c++-common/substring-location-PR-87562-1.c trunk/gcc/testsuite/gcc.dg/plugin/pr87562-a.h trunk/gcc/testsuite/gcc.dg/plugin/pr87562-b.h Modified: trunk/gcc/ChangeLog trunk/gcc/input.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/plugin/diagnostic-test-string-literals-1.c
[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 David Malcolm changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #5 from David Malcolm --- *** Bug 87643 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 David Malcolm changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from David Malcolm --- *** Bug 87630 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-10-17 Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from David Malcolm --- (In reply to Renlin Li from comment #2) > I checked that, the ICE starts from r264887. Thanks. I'm now able to reproduce this; am attempting to reduce the reproducer.
[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 Renlin Li changed: What|Removed |Added CC||renlin at gcc dot gnu.org --- Comment #2 from Renlin Li --- (In reply to David Malcolm from comment #1) > linemap_position_for_line_and_column(line_maps*, line_map_ordinary const*, > unsigned int, unsigned int) at libcpp/line-map.c:848 > is: > linemap_assert (ORDINARY_MAP_STARTING_LINE_NUMBER (ord_map) <= line); > > I wonder if I introduced this in r264887 with the changes to input.c > (macro-handling and concatenated strings), which touched the function in the > next frame. > > I'll see if I can reproduce it. Hi David, I checked that, the ICE starts from r264887.
[Bug tree-optimization/87562] [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87562 --- Comment #1 from David Malcolm --- linemap_position_for_line_and_column(line_maps*, line_map_ordinary const*, unsigned int, unsigned int) at libcpp/line-map.c:848 is: linemap_assert (ORDINARY_MAP_STARTING_LINE_NUMBER (ord_map) <= line); I wonder if I introduced this in r264887 with the changes to input.c (macro-handling and concatenated strings), which touched the function in the next frame. I'll see if I can reproduce it.
