It appears to be a regression from 11.*, affecting 12.* and later. Compiler Explorer: https://godbolt.org/z/PY985hnff [510] % gcctk -v Using built-in specs. COLLECT_GCC=gcctk COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --disable-bootstrap --enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk --enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 15.0.0 20240604 (experimental) (GCC) [511] % [511] % gcctk -O2 small.c; ./a.out [512] % gcctk -O3 small.c [513] % ./a.out Aborted [514] % cat small.c struct a { int b; int c; } d, e[2]; int f, g, h; int main() { for (; f < 1; f++) { for (h = 0; h < 2; h++) { d = e[f]; g = e[1].c; e[f].c = 1; } } if (d.c != 1) __builtin_abort(); return 0; }
Confirmed.
it's loop distribution doing t2.c:7:12: optimized: Loop nest 1 distributed: split to 2 loops and 0 library calls. We get for (; f < 1; f++) { for (h = 0; h < 2; h++) { d = e[f]; } } for (; f < 1; f++) { for (h = 0; h < 2; h++) { g = e[1].c; e[f].c = 1; } } I think this is similar to the other still open issue where zero-distance inner loop dependences (&e[f].c doesnt't vary in the inner loop) cause issues with the interpretation of classical dependence analysis. I'm somewhat lost there. PR112859.
Started with r12-2097-g9f34b780b0461ec7b2b2defe96e44ab616ea2aa3
GCC 12.4 is being released, retargeting bugs to GCC 12.5.
So this maybe needs "add_inner_distances" as we have add_outer_distances? We still get only ( 0 0 ) as zero distance.
As the "duplicate" is mine, so is this. But don't hold your breath - I do not actually understand how dependence analysis should work here.