https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #7 from Joseph S. Myers ---
Note the difference between __builtin_isinf (C standard semantics, returns
unspecified nonzero value for an infinity) and __builtin_isinf_sign (stricter
semantics returning 1 for +Inf and -1 for -Inf).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
Georg-Johann Lay changed:
What|Removed |Added
Priority|P4 |P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #6 from GCC Commits ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:c57d73f4cd5ca61327406fc2521a2235dd49d12e
commit r13-8817-gc57d73f4cd5ca61327406fc2521a2235dd49d12e
Author: Georg-Johann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #5 from Georg-Johann Lay ---
(In reply to Richard Biener from comment #1)
> The issue is that we probably fold isinff early. On x86 I see already in
> .original:
>
> return !(ABS_EXPR u<= 3.4028234663852885981170418348451692544e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #4 from Georg-Johann Lay ---
The isinf part is fixied in v14.2+, but there is also isnan etc. which don't
currently habe an optabs entry, so defining a failing expander won't work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #3 from GCC Commits ---
The releases/gcc-14 branch has been updated by Georg-Johann Lay
:
https://gcc.gnu.org/g:9d08c55f7c99329f4289ad3a4157c2d8d8a78d8c
commit r14-10266-g9d08c55f7c99329f4289ad3a4157c2d8d8a78d8c
Author: Georg-Johan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115307
--- Comment #2 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:fabb545026f714b7d1cbe586f4c5bbf6430bdde3
commit r15-966-gfabb545026f714b7d1cbe586f4c5bbf6430bdde3
Author: Georg-Johann Lay
Date
