https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125597
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 9 Jun 2026, tnfchris at gcc dot gnu.org wrote: > 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. Sure, if you put that in the IL it would. > 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. Because all GIMPLE defs are supposed to be in the IL, apart from SSA_NAME_IS_DEFAULT_DEF ones. It's simply invalid/unexpected IL and passes should not have workarounds for that. > > 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. Yes, I want us to avoid even intermediate invalid GIMPLE because that can (as we see here) lead to all sorts of issues. > The above SCEV fix seems less hacky to me. Not to me.
