https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128351
--- Comment #1 from liu zhenyu <lzy20000419 at outlook dot com> --- The vectorizer dump shows the latch count of the main exit as `(b - e) * inv(3) + 2^64 - 1`, which is `2^64 - 1` for `b == e`, so `NITERS = NITERSM1 + 1` wraps to 0. `loop_niters_no_overflow` (tree-vect-loop.cc) still returns true because `get_max_loop_iterations` for the loop is 2147483646 from the *other* exit (`k > lim`). That bound limits how often the loop runs, not the value of the main exit's count. In an early-break loop the main exit count can be larger than the loop maximum exactly when that exit is never taken. The vector loop bound then becomes `bnd = niters >> 3 = 0`. After one vector iteration control skips the scalar epilogue and returns the wrong sum. Possible direction: for loops with early exits, only trust `get_max_loop_iterations` in `loop_niters_no_overflow` when the main exit is the only exit (or use the main exit's own niter bound). With ivopts enabled the vector exit test is rewritten so this input happens to come out right.
