https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106498
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. Before OMP expansion the loops do not define virtual operands.
After OMP expansion there's (useless) loop-around virtual operands.
SSA form is updated at
#0 update_ssa (update_flags=2048)
at /space/rguenther/src/gcc-clean/gcc/tree-into-ssa.cc:3377
#1 0x00000000023fad6d in expand_omp_taskreg (region=0x3614bb0)
at /space/rguenther/src/gcc-clean/gcc/omp-expand.cc:1511
#2 0x000000000242a485 in expand_omp (region=0x3614bb0)
at /space/rguenther/src/gcc-clean/gcc/omp-expand.cc:10353
#3 0x000000000242aac4 in execute_expand_omp ()
at /space/rguenther/src/gcc-clean/gcc/omp-expand.cc:10592
#4 0x000000000242ac3f in (anonymous namespace)::pass_expand_omp_ssa::execute (
this=0x349c290) at /space/rguenther/src/gcc-clean/gcc/omp-expand.cc:10681
#5 0x000000000126d265 in execute_one_pass (
pass=<opt_pass* 0x349c290 "ompexpssa"(174)>)
which ends up adding this virtual def. The reason is a __builtin_GOMP_parallel
but the use is in a if (0 != 0) guarded region (that's possibly outlined
afterwards?).
It's quite ugly, SSA omp-expansion performs update_ssa sometimes per stmt!
SSA omp-expansion test coverage is quite weak and autopar isn't well maintained
:/
I do have a patch for this particular case though.
