https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125597

--- Comment #5 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
So this isn't an early break bug, but a generic masking one (the bitint code
has multiple loops).

Since masked loops were introduced during peeling we'd create the dummy
variable which is then filled in when vect_set_loop_condition is called.

This particular issue started with

commit g:4ac080e384cd30d37fac069d791b813100e6524a
Author: Andrew MacLeod <[email protected]>
Date:   Mon Jan 19 13:44:25 2026 -0500

    Do not trap on a stmt with no basic block.

    WHen calculating ranges for statements not in the IL, avoid looking for
    range on entry values.

            PR tree-optimization/123314
            gcc/
            * gimple-range.cc (gimple_ranger::range_on_entry): Do not check
            ranger cache for an SSA_NAME with no BB.
            (gimple_ranger::prefill_stmt_dependencies): Stop filling
            dependencies when an out-of IL name is encountered.

            gcc/testsuite/
            * gcc.dg/pr123314.c: New.

Because Ranger would now no longer check the cache for out of IL statements and
instead forces a re-analysis.
Eventually it ends up in SCEV which requires that the statement be in IL.

So it's not the fact that it's a GIMPLE_NOP that's the problem but that it's
out of IL and using .VARYING still keeps it out of IL so that didn't fix it.

the question is why does SCEV need it in IL? given that the only reason for
this is to determine if the variable is in the loop or not.  logically
speaking, if it's not in IL it can't be in the loop.


diff --git a/gcc/tree-scalar-evolution.cc b/gcc/tree-scalar-evolution.cc
index 279ff46474e..2954ff7a55a 100644
--- a/gcc/tree-scalar-evolution.cc
+++ b/gcc/tree-scalar-evolution.cc
@@ -2023,6 +2023,14 @@ analyze_scalar_evolution_1 (class loop *loop, tree var)

   def = SSA_NAME_DEF_STMT (var);
   bb = gimple_bb (def);
+  if (!bb)
+    {
+      /* If we don't know where the variable is, just keep the symbolic
+        form.  */
+      res = chrec_dont_know;
+      goto set_and_end;
+    }
+
   def_loop = bb->loop_father;

   if (!flow_bb_inside_loop_p (loop, bb))

Fixes it, and allows the various forms in the vectorizer where we fold out of
IL statements before inserting to continue working.

Or do you want me to force these temporary placeholders into the IL Richi? My
concern here is that we can create a use-before-def issue because any new
statements emitted must be in the right order whereas now we just build up seq
and flush at the gcond GSI.

The above SCEV fix seems less hacky to me.

Reply via email to