https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125689
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2026-06-30
--- Comment #4 from Jeffrey A. Law <law at gcc dot gnu.org> ---
My bisect landed on this as "fixing" the problem:
commit 1fb998f8839b31e91fb154bbf052e9470f083ef6
Author: Abhishek Kaushik <[email protected]>
Date: Tue Jun 16 07:43:50 2026 -0600
[PATCH] tree-optimization: Query ranger on edge for niter bound expressions
determine_value_range only queried ranger when VAR was an SSA_NAME.
However, number_of_iterations_exit_assumptions calls
expand_simple_operations on the IV bases before asking for the range.
This can expose simple GENERIC expressions, including conversions, even
when the original value had an SSA_NAME with useful range information.
Ranger can analyze such expressions at a program point or edge, so query
it for integral bound expressions on the loop preheader edge rather than
restricting the query to SSA_NAMEs. This lets niter analysis recover the
narrower range for value-preserving conversions such as uint8_t to int,
while still handling non-value-preserving conversions and wrapping
expressions conservatively.
The new test covers a direct converted uint8_t bound, a masked uint16_t
bound whose useful range comes from ranger, a guarded uint16_t bound
whose range is context-sensitive, a non-value-preserving uint8_t to
int8_t conversion, and a wrapping unsigned expression.
But IMHO, that's likely just making it go latent.
