https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97501
Bug ID: 97501
Summary: [11 Regression] ICE in verify_range, at
value-range.cc:369, -O2 on dead overflowing nested
loops
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mwindsor at imperial dot ac.uk
Target Milestone: ---
When compiling code including an (unreachable) nested pair of over/underflowing
loops, recent git versions of GCC11 experience an ICE in value-range.cc:369.
This seems a different bug from #96430, #97317, and #97467: eg it contains no
bitshifts or casts, and exhibits on snapshots after the most recent of those
bugs was fixed.
I am seeing this on git revision `f0c0f124ebe28b71abccbd7247678c9ac608b649`
(fetched 2020-10-20) on x86_64-pc-linux-gnu, on which this report is based. I
have also seen this on, for instance, revision
`8949b985dbaf07d433bd57d2883e1e5414f20e75` (fetched 2020-10-13) on
powerpc64le-unknown-linux-gnu. GCC 10.2.0 on x86_64-apple-darwin19 does NOT
exhibit the ICE, so I presume this is a GCC11 regression. I'm unsure of the
first revision to exhibit this at the moment.
Considering the following example (`mwe-full.c`; preprocessing gives the same
file modulo line directives):
===
static int c = 0;
int main() {
int b = 0;
if (c) {
for (;; b--)
do
b++;
while (b);
}
}
===
(This comes from a C-Reduced version which didn't have the check on `c`; I
added this to avoid run-time-live UB, but the bug exhibits without it)
`gcc -O2 -v -save-temps mwe-full.c` gives me:
===
Using built-in specs.
COLLECT_GCC=/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20/bin/gcc
COLLECT_LTO_WRAPPER=/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /data/mwindsor/old_compilers/gcc-snapshots/git/configure
--prefix=/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201020 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O2' '-v' '-save-temps' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1
-E -quiet -v -imultiarch x86_64-linux-gnu mwe-full.c -mtune=generic
-march=x86-64 -O2 -fpch-preprocess -o a-mwe-full.i
ignoring non-existent directory "/usr/local/include/x86_64-linux-gnu"
ignoring non-existent directory
"/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20/lib/gcc/x86_64-pc-linux-gnu/11.0.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include
/usr/local/include
/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20/include
/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20/lib/gcc/x86_64-pc-linux-gnu/11.0.0/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-O2' '-v' '-save-temps' '-mtune=generic' '-march=x86-64'
'-dumpdir' 'a-'
/data/mwindsor/old_compilers/gcc-snapshots/2020-10-20/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/cc1
-fpreprocessed a-mwe-full.i -quiet -dumpdir a- -dumpbase mwe-full.c
-dumpbase-ext .c -mtune=generic -march=x86-64 -O2 -version -o a-mwe-full.s
GNU C17 (GCC) version 11.0.0 20201020 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20201020 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C17 (GCC) version 11.0.0 20201020 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 11.0.0 20201020 (experimental), GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 8980ce301bb16f6f8206916710982a55
during GIMPLE pass: evrp
mwe-full.c: In function ‘main’:
mwe-full.c:11:1: internal compiler error: in verify_range, at
value-range.cc:369
11 | }
| ^
0x78f55b irange::verify_range()
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/value-range.cc:369
0x10d9d03 irange::irange_set(tree_node*, tree_node*)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/value-range.cc:172
0x10d9d03 irange::set(tree_node*, tree_node*, value_range_kind)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/value-range.cc:226
0x10d8f4c irange::operator=(irange const&)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/value-range.cc:40
0x18c168e gimple_ranger::range_of_stmt(irange&, gimple*, tree_node*)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/gimple-range.cc:996
0x18bdea8 gimple_ranger::range_of_expr(irange&, tree_node*, gimple*)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/gimple-range.cc:883
0x10d5cdd range_query::value_of_expr(tree_node*, gimple*)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/value-query.cc:85
0x175f681 hybrid_folder::value_of_expr(tree_node*, gimple*)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/gimple-ssa-evrp.c:235
0xf8fc96 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/tree-ssa-propagate.c:1072
0x1737187 dom_walker::walk(basic_block_def*)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/domwalk.c:309
0xf8f2c5 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/tree-ssa-propagate.c:1283
0x175f2f6 execute_early_vrp
/data/mwindsor/old_compilers/gcc-snapshots/git/gcc/gimple-ssa-evrp.c:349
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.
===
(old_compilers is a misnomer in the above!)
The ICE also exhibits under -O3, but not under -O1 or -O0. Turning on -fwrapv
or -fsanitize=undefined *suppresses* the ICE, so it seems related to the loop
overflow. Neither -fnostrict-aliasing nor -fno-aggressive-loop-optimizations
produce any change, and running the -O2 compilation result with either wrapv or
UBsan produces no run-time errors.
