https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98343
Bug ID: 98343
Summary: [11 Regression] ICE in in relocate_ptrs, at
ggc-common.c:363 [PCH and C++20 std::source_location?]
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: [email protected]
Target Milestone: ---
Host: x86_64-w64-mingw32 x86_64-linux-gnu
Target: aarch64-none-elf
Created attachment 49786
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49786&action=edit
An input header using std::source_location::current().
Hi.
Using GCC11 trunk built on 15.12.2020 @ x86_64-w64-mingw32 and 16.12.2020 @
x86_64-linux-gnu (sorry, unable to the latest trunk due to PR98300).
When attempting to precompile the following input header file GCC will ICE at
ggc-common. However that happens only, and only if, certain warnings are
enabled. `-Wall' will trigger this, and to be more precise any of the
following warnings: `-Wformat', `-Wnonnull' or `-Wrestrict'.
I do know if `std::source_location' is a red herring, or the warning flags, but
using a (large) real life file when the ICE occurs all symptoms point (dumping
a corresponding troublesome hash table) to locations which use
`std::source_location::current()'. Again, without `-Wall', PCH is compiled
just fine. (The resulting GCH is over 128 MB.)
I'm able to reproduce this on both Windows and Linux. I quickly tried a GCC10
(Windows) GCC9 (Linux) and they work just fine with that input file (though
those where not aarch64 targets; I presume this really has nothing to with the
target).
$ cat pch.hpp
#if __has_include(<source_location>)
#include <source_location>
#else
#include <experimental/source_location>
namespace std { using namespace experimental; }
#endif
extern void location_fun(std::source_location loc =
std::source_location::current());
$ aarch64-none-elf-g++ -std=c++20 -c pch.hpp -Wall
pch.hpp:2:85: internal compiler error: in relocate_ptrs, at ggc-common.c:363
2 | extern void location_fun(std::source_location loc =
std::source_location::current());
$ aarch64-none-elf-g++ -std=c++20 -c pch.hpp -Wall -wrapper gdb,--args
(gdb) break fancy_abort
(gdb) run
Thread 1 hit Breakpoint 1, fancy_abort (
file=0x1eefb00 <(anonymous namespace)::pass_data_rtl_pre+576>
"<...>/src/gcc/gcc/ggc-common.c", line=363, function=0x1eefbc2 <(anonymous
namespace)::pass_data_rtl_pre+770> "relocate_ptrs")
at <...>/src/gcc/gcc/diagnostic.c:1835
(gdb) bt
#0 fancy_abort (
file=0x1eefb00 <(anonymous namespace)::pass_data_rtl_pre+576>
"<...>/src/gcc/gcc/ggc-common.c", line=363, function=0x1eefbc2 <(anonymous
namespace)::pass_data_rtl_pre+770> "relocate_ptrs")
at <...>/src/gcc/gcc/diagnostic.c:1835
#1 0x0000000001c15cc8 in relocate_ptrs (ptr_p=0x210ea9b0, state_p=<optimized
out>)
at <...>/src/gcc/gcc/ggc-common.c:351
#2 relocate_ptrs (ptr_p=0x210ea9b0, state_p=<optimized out>)
at <...>/src/gcc/gcc/ggc-common.c:351
#3 0x0000000000471ea6 in ggc_remove<source_location_table_entry>::pch_nx
(cookie=0x1cf0fab0,
op=0x8d75e0 <relocate_ptrs(void*, void*)>, p=...) at
<...>/src/gcc/gcc/hash-traits.h:255
#4 hashtab_entry_note_pointers<source_location_table_entry_hash>
(obj=<optimized out>, h=0x210d5960,
op=0x8d75e0 <relocate_ptrs(void*, void*)>, cookie=0x1cf0fab0)
at <...>/src/gcc/gcc/hash-table.h:1181
#5 0x00000000008d7d70 in gt_pch_save (f=<optimized out>) at
<...>/src/gcc/gcc/ggc-common.c:549
#6 0x00000000006b72d8 in c_common_write_pch () at
<...>/src/gcc/gcc/c-family/c-pch.c:177
#7 0x00000000004ce405 in c_parse_final_cleanups () at
<...>/src/gcc/gcc/cp/decl2.c:4911
#8 0x0000000000bc34a2 in compile_file () at <...>/src/gcc/gcc/toplev.c:457
#9 0x0000000001c8ff38 in do_compile () at <...>/src/gcc/gcc/toplev.c:2193
#10 toplev::main (this=this@entry=0x1cf0fe0e, argc=<optimized out>,
argc@entry=19, argv=<optimized out>,
argv@entry=0x1f7425b0) at <...>/src/gcc/gcc/toplev.c:2332
#11 0x0000000001df7107 in main (argc=19, argv=0x1f7425b0) at
<...>/src/gcc/gcc/main.c:39
(gdb) print *((hash_table<source_location_table_entry_hash, false,
xcallocator>*)0x210d5960)
$1 = {m_entries = 0x210ea800, m_size = 127, m_n_elements = 1, m_n_deleted = 0,
m_searches = 1, m_collisions = 0,
m_size_prime_index = 4, m_ggc = true, m_sanitize_eq_and_hash = true, static
m_gather_mem_stats = false}
(gdb) print *((hash_table<source_location_table_entry_hash, false,
xcallocator>*)0x210d5960)->m_entries@127
$2 = {{loc = 0, uid = 0, var = 0x0} <repeats 27 times>, {loc = 10262528, uid =
4294967295, var = 0x210eb2d0}, {
loc = 0, uid = 0, var = 0x0} <repeats 99 times>}
(gdb) call expand_location (10262528)
$3 = {file = 0x1cf91790 "pch.hpp", line = 7, column = 83, data = 0x0, sysp =
false}
I noticed that on a few times `expand_location' displayed incorrect line or
column information for the given input location -- so, the real issue might be
buried quite deep. (I was using an older GDB9, so it might an issue, too.)
I used this to probe the problematic warnings. I took the list from
documentation, I presume it should be pretty complete.
$ for flag in -Waddress -Warray-bounds=1 -Wbool-compare -Wbool-operation
-Wc++11-compat -Wc++14-compat -Wcatch-value -Wchar-subscripts -Wcomment
-Wformat -Wformat-overflow -Wformat-truncation -Wint-in-bool-context
-Winit-self -Wlogical-not-parentheses -Wmaybe-uninitialized -Wmemset-elt-size
-Wmemset-transposed-args -Wmisleading-indentation -Wmissing-attributes
-Wmultistatement-macros -Wnarrowing -Wnonnull -Wnonnull-compare -Wopenmp-simd
-Wparentheses -Wpessimizing-move -Wreorder -Wrestrict -Wreturn-type
-Wsequence-point -Wsign-compare -Wsizeof-pointer-div -Wsizeof-pointer-memaccess
-Wstrict-aliasing -Wstrict-overflow=1 -Wswitch -Wtautological-compare
-Wtrigraphs -Wuninitialized -Wunknown-pragmas -Wunused-function -Wunused-label
-Wunused-value -Wunused-variable -Wvolatile-register-var -Wzero-length-bounds;
do builtin echo $flag; aarch64-none-elf-g++ -std=c++20 -c pch.hpp $flag; done
