Re: Calling conventions (particularly 32-bit ARM)

On 14/01/2025 15:39, Scott Lurndal wrote:

David Brown <david.brown@hesbynett.no> writes:

On 13/01/2025 23:40, Scott Lurndal wrote:

mitchalsup@aol.com (MitchAlsup1) writes:

On Mon, 13 Jan 2025 21:53:55 +0000, Scott Lurndal wrote:
>

mitchalsup@aol.com (MitchAlsup1) writes:

On Mon, 13 Jan 2025 18:02:10 +0000, Thomas Koenig wrote:
>

MitchAlsup1 <mitchalsup@aol.com> schrieb:
>

errno is an atrocity all by itself; single handedly preventing
direct use of SIN(), COS(), TAN(), ATAN(), exp(), ln(), pow()
as instructions.

>
Fortunately, the C standard does not require errno to be set
for these functions.  Apple, for example, does not do so.

>
Nor will I.

>
POSIX does, however, require errno to be set conditionally
based on an application global variable 'math_errhandling'.

>
The functions mentioned have the property of taking x as
any IEEE 754 number (including NaNs, infinities, denorms)
and produce a IEEE 754 number {NaNs, infinities, norms,
denorms}.
>
But if POSIX wants to spend as many cycles setting errno
as performing the calculation, that is for POSIX to decide.

>
POSIX leaves it up to the programmer to decide.  If the
programmer desires EDOM or ERANGE, they set the
appropriate bit in math_errhandling before calling the
sin et alia functions.
>

>
You know POSIX better than I do, but AFAIK "math_errhandling" is a fixed
value set by the implementation, usually as a macro.  Certainly with a
quick check with gcc on Linux, I could not set the bits in math_errhandling.
>

 Yes, the programmer in this case would instruct the compiler what
the value of math_errhandling should be, e.g. with --ffast-math.
 https://gcc.gnu.org/wiki/FloatingPointMath

I would say the key flag here is "-fno-math-errno" (which is included in -ffast-math).  While I personally think most floating point code could be used just as well with "-ffast-math", and it is certainly appropriate for my own code, others have significantly different opinions or experiences.  (That's fair enough.)  That one flag simply disables setting errno in maths functions that can (reasonably) be implemented inline as instructions, without affecting the results of any other floating point operations.
But to my mind, this is /not/ a case of the POSIX programmer making the choice - it is an implementation-specific feature.  A C compiler might choose to always use errno, or never, or have some other control of the use of errno.  When you write "POSIX leaves it up to the programmer", I take that to mean POSIX specifies a function that lets you change the value of "math_errhandling".  That is quite different from saying "gcc has a flag that lets you choose".
(For my own use, I like the flag - I don't write POSIX code, I have never had any use for errno, and I want the compiler to generate as few instructions as it possibly can.)