https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125597
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2026-06-05
CC| |rguenth at gcc dot gnu.org,
| |tnfchris at gcc dot gnu.org
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(gdb) p debug_gimple_stmt (at_stmt)
_42 = _38;
(gdb) p debug_tree (var)
<ssa_name 0x7ffff757f2c0
type <integer_type 0x7ffff761c000 sizetype public unsigned DI
size <integer_cst 0x7ffff761e000 constant 64>
unit-size <integer_cst 0x7ffff761e018 constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff761c000 precision:64 min <integer_cst 0x7ffff761e030 0> max <integer_cst
0x7ffff7603700 18446744073709551615>>
def_stmt GIMPLE_NOP
version:38>
and we hit this from vect_do_peeling, this is likely the "later to be
initialized" niter thing we've introduced lately?
3955 LOOP_VINFO_NITERSM1 (epilogue_vinfo)
3956 = fold_build2 (MINUS_EXPR, TREE_TYPE (epilogue_niters),
3957 epilogue_niters,
3958 build_one_cst (TREE_TYPE (epilogue_niters)));
I suspect we need to resort to a more "temporarily VARYING" way here :/
ISTR suggesting some internal function, like insert
_38 = .VARYING ();
it would be a NOVOPS (but not CONST/PURE) one maybe.
