Hi All,
These three value range patches were committed as r15-2922, r15-2923 and
r15-2924.
Thanks
Gui Haochen
在 2024/8/15 5:46, Jeff Law 写道:
>
>
> On 8/14/24 12:38 PM, Sam James wrote:
>> Vineet Gupta writes:
>>
>>> Ping - looks like this is blocking the patches for builtin_isnormal and
>>
On 8/14/24 12:38 PM, Sam James wrote:
Vineet Gupta writes:
Ping - looks like this is blocking the patches for builtin_isnormal and
builtin_isfinite !
See
https://inbox.sourceware.org/gcc-patches/d9459db0-7301-40f6-a3cf-077017b8c...@gmail.com/.
It appears to be approved.
(Please also
On 8/14/24 11:38, Sam James wrote:
>> Ping - looks like this is blocking the patches for builtin_isnormal and
>> builtin_isfinite !
>>
> See
> https://inbox.sourceware.org/gcc-patches/d9459db0-7301-40f6-a3cf-077017b8c...@gmail.com/.
>
> It appears to be approved.
Sorry, should have refreshed
Vineet Gupta writes:
> Ping - looks like this is blocking the patches for builtin_isnormal and
> builtin_isfinite !
>
See
https://inbox.sourceware.org/gcc-patches/d9459db0-7301-40f6-a3cf-077017b8c...@gmail.com/.
It appears to be approved.
(Please also avoid topposting.)
> Thx,
> -Vineet
>
>
Ping - looks like this is blocking the patches for builtin_isnormal and
builtin_isfinite !
Thx,
-Vineet
On 8/5/24 07:51, Jeff Law wrote:
>
> On 7/23/24 4:39 PM, Andrew MacLeod wrote:
>> the range is in r, and is set to [0,0]. this is the false part of what
>> is being returned for the range.
>
On 8/14/24 1:04 AM, HAO CHEN GUI wrote:
Hi Jeff,
May I know your final decision on this patch?
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656937.html
I thought I acked the whole set.
Jeff
Hi Jeff,
May I know your final decision on this patch?
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656937.html
Thanks
Gui Haochen
在 2024/8/5 22:51, Jeff Law 写道:
>
>
> On 7/23/24 4:39 PM, Andrew MacLeod wrote:
>> the range is in r, and is set to [0,0]. this is the false part of what
On 7/23/24 4:39 PM, Andrew MacLeod wrote:
the range is in r, and is set to [0,0]. this is the false part of what
is being returned for the range.
the "return true" indicates we determined a range, so use what is in R.
returning false means we did not find a range to return, so r is garbage
Hi Jeff,
Do you have further questions?
Thanks
Gui Haochen
在 2024/7/24 6:39, Andrew MacLeod 写道:
>
> On 7/23/24 15:18, Jeff Law wrote:
>>
>>
>> On 7/11/24 9:17 PM, HAO CHEN GUI wrote:
>>
So why the test for real_isinf on the upper/lower bound? If op1 is known
to be a NaN, then why t
On 7/23/24 15:18, Jeff Law wrote:
On 7/11/24 9:17 PM, HAO CHEN GUI wrote:
So why the test for real_isinf on the upper/lower bound? If op1 is
known to be a NaN, then why test the bounds at all? If a bounds
test is needed, why only test the upper bound?
IMHO, logical is if the op1 is a N
On 7/11/24 9:17 PM, HAO CHEN GUI wrote:
So why the test for real_isinf on the upper/lower bound? If op1 is known to be
a NaN, then why test the bounds at all? If a bounds test is needed, why only
test the upper bound?
IMHO, logical is if the op1 is a NAN, it's not an infinite number. If
Hi Jeff,
Thanks for your comments.
在 2024/7/12 6:13, Jeff Law 写道:
>
>
> On 7/11/24 1:32 AM, HAO CHEN GUI wrote:
>> Hi,
>> The builtin isinf is not folded at front end if the corresponding optab
>> exists. It causes the range evaluation failed on the targets which has
>> optab_isinf. For ins
On 7/11/24 1:32 AM, HAO CHEN GUI wrote:
Hi,
The builtin isinf is not folded at front end if the corresponding optab
exists. It causes the range evaluation failed on the targets which has
optab_isinf. For instance, range-sincos.c will fail on the targets which
has optab_isinf as it calls bui
I have no issues with any of the range-op work in this patch series,
but I am unequipped to review the floating point aspects of any of the
patches.
We just need someone to signoff that this properly reflects those builtins.
Andrew
On 7/11/24 03:32, HAO CHEN GUI wrote:
Hi,
The builtin i
14 matches
Mail list logo
