Re: [PATCH] range-op-float: Further comparison fixes

2023-04-01 Thread Aldy Hernandez via Gcc-patches
On 4/1/23 09:39, Jakub Jelinek wrote: On Fri, Mar 31, 2023 at 01:28:35PM +0200, Aldy Hernandez wrote: Ok for trunk if this passes bootstrap/regtest? LGTM Unfortunately I ran into 4 tests where we run into the known bug where if ranger finds out a range of some floating point operation it

Re: [PATCH] range-op-float: Further comparison fixes

2023-04-01 Thread Jakub Jelinek via Gcc-patches
On Fri, Mar 31, 2023 at 01:28:35PM +0200, Aldy Hernandez wrote: > > Ok for trunk if this passes bootstrap/regtest? > > LGTM Unfortunately I ran into 4 tests where we run into the known bug where if ranger finds out a range of some floating point operation it folds it and throws away the trapping

Re: [PATCH] range-op-float: Further comparison fixes

2023-03-31 Thread Aldy Hernandez via Gcc-patches
On 3/31/23 12:45, Jakub Jelinek wrote: On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote: and so if maybe_isnan, they always return [0, 1]. Now, thinking about it, this is unnecessary pessimization, for the case where the ... block returns range_false (type) we ac

[PATCH] range-op-float: Further comparison fixes

2023-03-31 Thread Jakub Jelinek via Gcc-patches
On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote: > and so if maybe_isnan, they always return [0, 1]. Now, thinking about it, > this is unnecessary pessimization, for the case where the ... block > returns range_false (type) we actually could do it also if maybe_isnan