https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Ah, that seems like a bug in the recip pass. Before that we have # RANGE [frange] float [1.0e+0 (0x0.8p+1), 4.294967296e+9 (0x0.8p+33)] _4 = (float) _3; # RANGE [frange] float [1.0e+0 (0x0.8p+1), 6.5536e+4 (0x0.8p+17)] _5 = sqrtf (_4); # RANGE [frange] float [7.62939453125e-6 (0x0.8p-16), 5.0e-1 (0x0.8p+0)] _6 = 5.0e-1 / _5; which is I think correct, 1.0 + unsigned int is [1.0, 0x1.p+32] and its square root is [1.0, 0x1.p+16]. But the recip pass reuses SSA_NAMEs (generally a bad idea) and keeps the ranges, so we get: # RANGE [frange] float [1.0e+0 (0x0.8p+1), 4.294967296e+9 (0x0.8p+33)] _4 = (float) _3; # RANGE [frange] float [1.0e+0 (0x0.8p+1), 6.5536e+4 (0x0.8p+17)] _5 = .RSQRT (_4); # RANGE [frange] float [7.62939453125e-6 (0x0.8p-16), 5.0e-1 (0x0.8p+0)] _6 = _5 * 5.0e-1; the range on _5 is obviously incorrect, .RQSRT computes 1 / sqrt.
