I get an ICE when building 502.gcc_r from SPEC2017 intrate for aarch64: $ gcc -c -o dbxout.o -DSPEC -DNDEBUG -I. -I./include -I./spec_qsort -DSPEC_502 -DSPEC_AUTO_SUPPRESS_OPENMP -DIN_GCC -DHAVE_CONFIG_H -DSPEC_LP64 dbxout.c during GIMPLE pass: printf-return-value dbxout.c: In function 'dbxout_stab_value_internal_label': dbxout.c:508:1: internal compiler error: in linemap_position_for_line_and_column, at libcpp/line-map.c:848 508 | dbxout_stab_value_internal_label (const char *stem, int *counterp) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 0x151f447 linemap_position_for_line_and_column(line_maps*, line_map_ordinary const*, unsigned int, unsigned int) $SRC/libcpp/line-map.c:848 0x1502388 get_substring_ranges_for_loc $SRC/gcc/input.c:1465 0x1502772 get_source_location_for_substring(cpp_reader*, string_concat_db*, unsigned int, cpp_ttype, int, int, int, unsigned int*) $SRC/gcc/input.c:1517 0x68071f c_get_substring_location(substring_loc const&, unsigned int*) $SRC/gcc/c-family/c-common.c:867 0xbf8f8a substring_loc::get_location(unsigned int*) const $SRC/gcc/substring-locations.c:284 0xbf8fef format_string_diagnostic_t::emit_warning_n_va(int, unsigned long, char const*, char const*, __va_list_tag (*) [1]) const $SRC/gcc/substring-locations.c:156 0xbf9258 format_string_diagnostic_t::emit_warning_va(int, char const*, __va_list_tag (*) [1]) const $SRC/gcc/substring-locations.c:241 0x13cbd6f fmtwarn $SRC/gcc/gimple-ssa-sprintf.c:472 0x13cc83e maybe_warn $SRC/gcc/gimple-ssa-sprintf.c:2564 0x13d2229 format_directive $SRC/gcc/gimple-ssa-sprintf.c:2823 0x13d2229 compute_format_length $SRC/gcc/gimple-ssa-sprintf.c:3502 0x13d2229 handle_gimple_call $SRC/gcc/gimple-ssa-sprintf.c:3988 0x13d2229 before_dom_children $SRC/gcc/gimple-ssa-sprintf.c:4027 0x1384ad7 dom_walker::walk(basic_block_def*) $SRC/gcc/domwalk.c:353 0x13ce8ed execute $SRC/gcc/gimple-ssa-sprintf.c:4053 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. Unfortunately this is not reproducible when compiling with -save-temps or when using the preprocessed file, so I can't reduce it.
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.
(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.
(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 87630 has been marked as a duplicate of this bug. ***
*** Bug 87643 has been marked as a duplicate of this bug. ***
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
Should be fixed by r265271. Sorry for the breakage.
Build successes for intrate: 502.gcc_r(base) Build errors for intrate: None It now works with your fix, thanks!
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