Re: [PATCH] Add __builtin_iseqsig()

[Richard Biener via Gcc-patches]

On Wed, 19 Jul 2023, FX Coudert wrote:

> 6 weeks later, I?d like to ask a global maintainer to review this.
> The idea was okay?ed previously by Joseph Myers, but he asked for testing of 
> both the quiet and signalling NaN cases, which is now done.

OK.

Thanks,
Richard.

> FX
> 
> 
> > Le 6 juin 2023 ? 20:15, FX Coudert  a ?crit :
> > 
> > Hi,
> > 
> > (It took me a while to get back to this.)
> > 
> > This is a new and improved version of the patch at 
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html
> > It addresses the comment from Joseph that FE_INVALID should really be 
> > tested in the case of both quiet and signaling NaNs, which is now done 
> > systematically.
> > 
> > Bootstrapped and regtested on x86_64-pc-linux-gnu
> > OK to commit?
> > 
> > FX
> > 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: [PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

6 weeks later, I’d like to ask a global maintainer to review this.
The idea was okay’ed previously by Joseph Myers, but he asked for testing of 
both the quiet and signalling NaN cases, which is now done.

FX


> Le 6 juin 2023 à 20:15, FX Coudert  a écrit :
> 
> Hi,
> 
> (It took me a while to get back to this.)
> 
> This is a new and improved version of the patch at 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html
> It addresses the comment from Joseph that FE_INVALID should really be tested 
> in the case of both quiet and signaling NaNs, which is now done 
> systematically.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu
> OK to commit?
> 
> FX
> 


0001-Add-__builtin_iseqsig.patch
Description: Binary data

Re: [PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

ping**3


>> Le 6 juin 2023 à 20:15, FX Coudert  a écrit :
>> 
>> Hi,
>> 
>> (It took me a while to get back to this.)
>> 
>> This is a new and improved version of the patch at 
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html
>> It addresses the comment from Joseph that FE_INVALID should really be tested 
>> in the case of both quiet and signaling NaNs, which is now done 
>> systematically.
>> 
>> Bootstrapped and regtested on x86_64-pc-linux-gnu
>> OK to commit?
>> 
>> FX



0001-Add-__builtin_iseqsig.patch
Description: Binary data

Re: [PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

ping**2


> Le 6 juin 2023 à 20:15, FX Coudert  a écrit :
> 
> Hi,
> 
> (It took me a while to get back to this.)
> 
> This is a new and improved version of the patch at 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html
> It addresses the comment from Joseph that FE_INVALID should really be tested 
> in the case of both quiet and signaling NaNs, which is now done 
> systematically.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu
> OK to commit?
> 
> FX
> 
> <0001-Add-__builtin_iseqsig.patch>


0001-Add-__builtin_iseqsig.patch
Description: Binary data

Re: [PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

ping


> Hi,
> 
> (It took me a while to get back to this.)
> 
> This is a new and improved version of the patch at 
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html
> It addresses the comment from Joseph that FE_INVALID should really be tested 
> in the case of both quiet and signaling NaNs, which is now done 
> systematically.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu
> OK to commit?
> 
> FX


0001-Add-__builtin_iseqsig.patch
Description: Binary data

[PATCH] Add __builtin_iseqsig()

[FX Coudert via Gcc-patches]

Hi,

(It took me a while to get back to this.)

This is a new and improved version of the patch at 
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602932.html
It addresses the comment from Joseph that FE_INVALID should really be tested in 
the case of both quiet and signaling NaNs, which is now done systematically.

Bootstrapped and regtested on x86_64-pc-linux-gnu
OK to commit?

FX



0001-Add-__builtin_iseqsig.patch
Description: Binary data

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

Hi,

> Joseph's reply earlier in this thread has indicated a desire to verify that 
> verifies FE_INVALID is raised when appropriate and not raised when 
> inappropriate when the arguments come from volatile variables rather than 
> directly from constants.
> 
> The patch itself looks pretty reasonable.  So let's get the testing coverage 
> Joseph wanted so we can move forward.

Sadly, while I had some time to deal with it when the patch was originally 
submitted, once the review came back my hands were full and right now I cannot 
find time. I hope someone can pick it up and finish, otherwise it will have to 
wait for the next version.

FX

Re: [PATCH] Add __builtin_iseqsig()

[Jeff Law via Gcc-patches]

On 10/31/22 13:15, FX wrote:

Hi,

Just adding, from the Fortran 2018 perspective, things we will need to 
implement for which I think support from the middle-end might be necessary:

- rounded conversions: converting, from an integer or floating point type, into 
another floating point type, with specific rounding mode passed as argument
- conversion to integer: converting, from a floating point type, into an 
integer type, with specific rounding mode passed as argument
- IEEE operations corresponding to nextDown and nextUp (or are those already 
available? I have not checked the fine print)

I would like to add them all for GCC 13.


If you want them all for GCC 13, then you're going to need to make a 
case for a policy exception to add them after stage1 has closed.



Joseph's reply earlier in this thread has indicated a desire to verify 
that verifies FE_INVALID is raised when appropriate and not raised when 
inappropriate when the arguments come from volatile variables rather 
than directly from constants.


The patch itself looks pretty reasonable.  So let's get the testing 
coverage Joseph wanted so we can move forward.



Jeff

Re: [PATCH] Add __builtin_iseqsig()

[Joseph Myers]

On Mon, 31 Oct 2022, FX via Gcc-patches wrote:

> - rounded conversions: converting, from an integer or floating point 
> type, into another floating point type, with specific rounding mode 
> passed as argument

These don't have standard C names.  The way to do these in C would be 
using the FENV_ROUND pragma around a conversion, but we don't support any 
of the standard pragmas including those from C99 and they would be a large 
project (cf. Marc Glisse's -ffenv-access patches from August 2020 - 
although some things in FENV_ACCESS are probably rather orthogonal to 
FENV_ROUND, I expect what's required in terms of preventing unwanted code 
movement across rounding mode changes is similar).

It might be possible to add built-in functions for such conversions 
without needing the FENV_ROUND machinery, if you make them expand to insn 
patterns (with temporary rounding mode changes) that are arranged so the 
compiler can't split them up.

(There's a principle of not introducing libm dependencies in code not 
using any ,  or  functions or corresponding 
built-in functions, which would be an issue for generating calls to 
fesetround, inline or in libgcc, from such an operation.  But arguably, 
even if FENV_ROUND shouldn't introduce such dependencies - my assumption 
being that FENV_ROUND should involve target-specific inline 
implementations of the required rounding mode changes - it might be OK to 
document some GCC-specific built-in function as doing so.)

> - conversion to integer: converting, from a floating point type, into an 
> integer type, with specific rounding mode passed as argument

See the fromfp functions (signed and unsigned versions, versions with and 
without raising inexact, rounding mode specified as one of the FP_INT_* 
macros from ).  The versions in TS 18661-1 produced results in an 
integer type (intmax_t / uintmax_t, with the actual width for the 
conversion passed as an argument).  *But* C2X changed that to return the 
result in a floating-point type instead (as part of reducing the use of 
intmax_t in interfaces) - I haven't yet implemented that change in glibc.  
So the way to do such a conversion to an integer type in C2X involves 
calling such a function and then converting its result to that integer 
type.

GCC certainly knows about handling such a pair ( function, 
conversion of its result) as a built-in function (e.g. __builtin_iceil).  
My guess is that in most cases only selected calls would be expanded 
inline - calls where not only is there an appropriate conversion to an 
integer type (matching, or maybe wider than, the width passed to the 
function), but where also the function, rounding mode and width together 
match an operation for which there is a hardware instruction, with other 
cases (including ones where the rounding mode or width aren't constant) 
ending up as runtime calls (unless optimized for constant arguments).  So 
while the interfaces exist in C2X, the built-in function support in GCC 
may be fairly complicated, with the existence of the older TS 18661-1 
version of the functions complicating things further.

> - IEEE operations corresponding to nextDown and nextUp (or are those 
> already available? I have not checked the fine print)

nextdown and nextup have been in glibc since version 2.24.  I expect that 
adding built-in functions that optimize them for constant arguments would 
be straightforward (that doesn't help if what you actually want it some 
way to support those operations at runtime for targets without the 
functions in libm, of course).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

Hi,

Just adding, from the Fortran 2018 perspective, things we will need to 
implement for which I think support from the middle-end might be necessary:

- rounded conversions: converting, from an integer or floating point type, into 
another floating point type, with specific rounding mode passed as argument
- conversion to integer: converting, from a floating point type, into an 
integer type, with specific rounding mode passed as argument
- IEEE operations corresponding to nextDown and nextUp (or are those already 
available? I have not checked the fine print)

I would like to add them all for GCC 13.

FX

Re: [PATCH] Add __builtin_iseqsig()

[Joseph Myers]

On Fri, 28 Oct 2022, Jeff Law via Gcc-patches wrote:

> Joseph, do you have bits in this space that are going to be landing soon, or
> is your C2X work focused elsewhere?  Are there other C2X routines we need to
> be proving builtins for?

I don't have any builtins work planned for GCC 13 (maybe adjustments to 
__builtin_tgmath semantics to match changes in C2X, but that's a keyword, 
not a built-in function).

See  
for my comments on (the tests in) this patch.

Lots of  functions could sensibly have built-in versions, whether 
for inline expansion, optimization for constant arguments or both.  Note 
that for those added from TS 18661-4, it will be more convenient to add 
glibc support once MPFR 4.2 is out so that gen-auto-libm-tests doesn't 
depend on an unreleased MPFR version, and likewise MPFR 4.2 will be needed 
for optimizing those functions for constant arguments.  But other 
highlights for which built-in functions might make sense in some cases 
include: issubnormal, iszero (see bugs 77925 / 77926, where Tamar 
Christina's patch needed to be reverted); probably the fromfp functions 
(but note that the interface in C2X is different from that in TS 18661-1 
and I haven't yet implemented those changes in glibc); the functions that 
round their result to a narrower type (supported as hardware operations on 
current POWER, I think); the functions bound to new maximum / minimum 
operations from I 754-2019 (some of which are supported by RISC-V 
instructions).  Also the  functions; I expect to implement those 
for glibc largely using existing built-in functions, but more direct 
built-in function support for the  names may make sense.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add __builtin_iseqsig()

[Jeff Law via Gcc-patches]

On 9/21/22 03:40, FX via Gcc-patches wrote:

ping*2




Le 9 sept. 2022 à 19:55, FX  a écrit :

ping



Le 1 sept. 2022 à 23:02, FX  a écrit :

Attached patch adds __builtin_iseqsig() to the middle-end and C family 
front-ends.
Testing does not currently check whether the signaling part works, because with 
optimisation is actually does not (preexisting compiler bug: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)

Bootstrapped and regtested on x86_64-linux.
OK to commit?

(I’m not very skilled for middle-end hacking, so I’m sure there will be 
modifications to make.)

FX
<0001-Add-__builtin_iseqsig.patch>


Joseph, do you have bits in this space that are going to be landing 
soon, or is your C2X work focused elsewhere?  Are there other C2X 
routines we need to be proving builtins for?



Jeff

Re: [PATCH] Add __builtin_iseqsig()

[Joseph Myers]

My reading of the bug given as a reason for not testing that FE_INVALID is 
raised for (both quiet and signaling) NaN arguments is that it's 
specifically about constant arguments.  That is, it ought to be possible 
to have a testcase that verifies FE_INVALID is raised when appropriate 
(and not when inappropriate) provided the arguments come from volatile 
variables rather than directly from constants.  (There would still need to 
be a powerpc*-*-* XFAIL referencing bug 58684.)  Only a test for constant 
arguments would need to wait on a fix for bug 106805.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

ping*3
please?


> Le 21 sept. 2022 à 11:40, FX  a écrit :
> 
> ping*2
> 
> <0001-Add-__builtin_iseqsig.patch>
> 
>> Le 9 sept. 2022 à 19:55, FX  a écrit :
>> 
>> ping
>> 
>> 
>>> Le 1 sept. 2022 à 23:02, FX  a écrit :
>>> 
>>> Attached patch adds __builtin_iseqsig() to the middle-end and C family 
>>> front-ends.
>>> Testing does not currently check whether the signaling part works, because 
>>> with optimisation is actually does not (preexisting compiler bug: 
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)
>>> 
>>> Bootstrapped and regtested on x86_64-linux.
>>> OK to commit?
>>> 
>>> (I’m not very skilled for middle-end hacking, so I’m sure there will be 
>>> modifications to make.)
>>> 
>>> FX
>>> <0001-Add-__builtin_iseqsig.patch>
>> 
> 

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

ping*2



0001-Add-__builtin_iseqsig.patch
Description: Binary data


> Le 9 sept. 2022 à 19:55, FX  a écrit :
> 
> ping
> 
> 
>> Le 1 sept. 2022 à 23:02, FX  a écrit :
>> 
>> Attached patch adds __builtin_iseqsig() to the middle-end and C family 
>> front-ends.
>> Testing does not currently check whether the signaling part works, because 
>> with optimisation is actually does not (preexisting compiler bug: 
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)
>> 
>> Bootstrapped and regtested on x86_64-linux.
>> OK to commit?
>> 
>> (I’m not very skilled for middle-end hacking, so I’m sure there will be 
>> modifications to make.)
>> 
>> FX
>> <0001-Add-__builtin_iseqsig.patch>
> 

Re: [PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

ping


> Le 1 sept. 2022 à 23:02, FX  a écrit :
> 
> Attached patch adds __builtin_iseqsig() to the middle-end and C family 
> front-ends.
> Testing does not currently check whether the signaling part works, because 
> with optimisation is actually does not (preexisting compiler bug: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)
> 
> Bootstrapped and regtested on x86_64-linux.
> OK to commit?
> 
> (I’m not very skilled for middle-end hacking, so I’m sure there will be 
> modifications to make.)
> 
> FX
> <0001-Add-__builtin_iseqsig.patch>

[PATCH] Add __builtin_iseqsig()

[FX via Gcc-patches]

Attached patch adds __builtin_iseqsig() to the middle-end and C family 
front-ends.
Testing does not currently check whether the signaling part works, because with 
optimisation is actually does not (preexisting compiler bug: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805)

Bootstrapped and regtested on x86_64-linux.
OK to commit?

(I’m not very skilled for middle-end hacking, so I’m sure there will be 
modifications to make.)

FX


0001-Add-__builtin_iseqsig.patch
Description: Binary data