Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2023-06-10 Thread FX Coudert via Gcc-patches
Hi Harald, > I just looked at that thread. I guess if you answer Mikael's > questions at > https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601744.html > the patch will be fine. Amended patch, adding the required testing of signalling vs. quiet behaviour. I still need to get an OK on th

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2023-06-08 Thread Harald Anlauf via Gcc-patches
Hi FX, Am 06.06.23 um 21:29 schrieb FX Coudert via Gcc-patches: Hi, This is a repost of the patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html which never really got green light, but I stopped pushing because stage 1 was closing and I was out of time. I just looke

[PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2023-06-06 Thread FX Coudert via Gcc-patches
Hi, This is a repost of the patch at https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600887.html which never really got green light, but I stopped pushing because stage 1 was closing and I was out of time. It depends on a middle-end patch adding a type-generic __builtin_iseqsig(), whi

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2022-09-17 Thread Mikael Morin
Le 02/09/2022 à 13:37, FX via Fortran a écrit : Hi, These operations were added to Fortran 2018, and correspond to well-defined IEEE comparison operations, with defined signaling semantics for NaNs. All are implemented in terms of GCC expressions and built-ins, with no library support needed.

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2022-09-02 Thread FX via Gcc-patches
> IIRC there was discussion about abort on the ML some years ago where folks > decided to switch to stop N. > I don't think I participated in that discussion, maybe somebody remembers the > reasoning or is able to find the thread. Found it: https://gcc.gnu.org/legacy-ml/fortran/2018-02/msg00105.

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2022-09-02 Thread Bernhard Reutner-Fischer via Gcc-patches
On 2 September 2022 17:54:00 CEST, FX wrote: >Hi Bernhard, > >> Please do not call the non-standard abort, but use stop N. > >Is there a specific reason? It’s a well-documented GNU extension, and it’s >useful because it can easily display a backtrace and give line info for the >failure, unlike S

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2022-09-02 Thread FX via Gcc-patches
Hi Bernhard, > Please do not call the non-standard abort, but use stop N. Is there a specific reason? It’s a well-documented GNU extension, and it’s useful because it can easily display a backtrace and give line info for the failure, unlike STOP. I’ll replace if there is consensus, but apart fr

Re: [PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2022-09-02 Thread Bernhard Reutner-Fischer via Gcc-patches
On 2 September 2022 13:37:41 CEST, FX via Fortran wrote: >Hi, Please do not call the non-standard abort, but use stop N. IIRC I once had a trivial script.. https://www.mail-archive.com/search?l=gcc-patches@gcc.gnu.org&q=subject:%22%5C%5BPATCH%2C+OpenACC%5C%5D+Fortran+deviceptr%22&o=newest&f=1

[PATCH] Fortran: add IEEE_QUIET_* and IEEE_SIGNALING_* comparisons

2022-09-02 Thread FX via Gcc-patches
Hi, These operations were added to Fortran 2018, and correspond to well-defined IEEE comparison operations, with defined signaling semantics for NaNs. All are implemented in terms of GCC expressions and built-ins, with no library support needed. Bootstrapped and regtested on x86_64-linux, both