Bug 87562 - [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line-map.c:848
Summary: [9 Regression] ICE in in linemap_position_for_line_and_column, at libcpp/line...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 9.0
: P3 normal
Target Milestone: 9.0
Assignee: David Malcolm
URL:
Keywords: diagnostic, ice-on-valid-code
: 87630 87643 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-10-09 09:12 UTC by ktkachov
Modified: 2018-10-29 23:59 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 9.0
Last reconfirmed: 2018-10-17 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ktkachov 2018-10-09 09:12:19 UTC
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.
Comment 1 David Malcolm 2018-10-09 10:17:09 UTC
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.
Comment 2 Renlin Li 2018-10-15 16:01:38 UTC
(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.
Comment 3 David Malcolm 2018-10-17 18:47:05 UTC
(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.
Comment 4 David Malcolm 2018-10-17 18:48:36 UTC
*** Bug 87630 has been marked as a duplicate of this bug. ***
Comment 5 David Malcolm 2018-10-18 14:51:41 UTC
*** Bug 87643 has been marked as a duplicate of this bug. ***
Comment 6 David Malcolm 2018-10-18 15:45:21 UTC
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
Comment 7 David Malcolm 2018-10-18 15:49:43 UTC
Should be fixed by r265271.  Sorry for the breakage.
Comment 8 seurer 2018-10-18 17:13:57 UTC
Build successes for intrate: 502.gcc_r(base)
Build errors for intrate: None

It now works with your fix, thanks!
Comment 9 David Malcolm 2018-10-29 23:59:06 UTC
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