On Fri, 1 Sep 2023, Richard Biener wrote:
The value of .CLZ (0) is undefined then. I belive your analysis is correct in
that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes
the range for _35. I wonder why we don't elide _36 ? _31 : 1 with that info
(possibly no range-op f
On Fri, Sep 01, 2023 at 10:13:40AM +0200, Richard Biener via Gcc wrote:
> The value of .CLZ (0) is undefined then. I belive your analysis is correct in
> that both 63 - _35 might overflow and that dom3 (thus ranger) mis-computes
> the range for _35. I wonder why we don't elide _36 ? _31 : 1 with
fixing this would still make the
> tool report a miscompilation as the ranges calculated during the dom3 pass
> claims that _35 has a range:
>_35 : [irange] int [0, 63]
>
> So what is the correct semantics for CLZ when CLZ_DEFINED_VALUE_AT_ZERO is
> false?
The value of .CLZ (0
correct semantics for CLZ when CLZ_DEFINED_VALUE_AT_ZERO is
false?
/Krister
