https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128188
Bug ID: 128188
Summary: vectorizer: compile-time hang in vect_simd_lane_linear
on nested omp simd with declare simd linear call
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Keywords: compile-time-hog
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dohanam2 at illinois dot edu
Target Milestone: ---
With nested `#pragma omp simd` loops, GCC at -O3 -fno-tree-loop-im
-fno-tree-pre hangs forever when the inner loop calls a `declare simd linear`
function with the address of a variable local to the outer loop body.
```c
#pragma omp declare simd linear(p:1) notinbranch
extern int update(int *p, int x);
void f(int *restrict d, const int *restrict a, int n, int m)
{
#pragma omp simd
for (int i = 0; i < n; i++)
{
int t = a[i];
#pragma omp simd
for (int j = 0; j < m; j++)
d[i*m+j] = update(&t, a[j]);
}
}
```
```
gcc -O3 -fopenmp-simd -fno-tree-loop-im -fno-tree-pre -c reduced.c -o /dev/null
```
cc1 never terminates and uses 100% CPU; there is no output. It was killed by
`timeout` after 30 s (exit status 124). Without the two `-fno-tree-*` options,
or with either one alone, it compiles in under 1 s. `-O2 -ftree-vectorize` in
place of `-O3` behaves the same. The input was generated by the testing tool,
not taken from a real program.
I expected the file to compile, since the code is valid OpenMP and an
unvectorizable call should just be left scalar or cloned.
Found at commit f16aa1c29ef9fe49ef11f9735e8d01954dfb8b01. Still reproduces at
4dee18cade51d955d9cd6dc86f4399be133a2821 (release build: killed at the
timeout). At f16aa1c29ef9 both the checking and the release build hang.
Looks like `vect_simd_lane_linear` in gcc/tree-vect-stmts.cc: in the `while
(TREE_CODE (v) == SSA_NAME)` walk, a definition that is a call to
`IFN_GOMP_SIMD_LANE` of the outer simd loop (not of `loop->simduid`) matches no
branch that returns or updates `v`, so the loop never exits. A SIGSEGV sent to
the running cc1 showed it in that function (line 4043) called from
`vectorizable_simd_clone_call`.
Found with an LLM-based testing tool; I used Claude to reduce it and look for
the cause.
