Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Calling conventions (particularly 32-bit ARM)
Date: Tue, 14 Jan 2025 16:50:26 +0100
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <vm6142$2fgsg$1@dont-email.me>
References: <vlgngv$1ks4a$1@dont-email.me>
 <jwvr05cq4tx.fsf-monnier+comp.arch@gnu.org>
 <2025Jan9.082357@mips.complang.tuwien.ac.at>
 <vlqm0d$27bfb$1@paganini.bofh.team>
 <2025Jan10.112523@mips.complang.tuwien.ac.at>
 <6be6d207cf7386fb66d47f2fe619df71@www.novabbs.org>
 <vm3kf2$1t0s1$1@dont-email.me>
 <6248473300a9fc0fd964c635510f510d@www.novabbs.org>
 <TXfhP.642290$Uup4.301463@fx10.iad>
 <a0867899b693a1bc2579ec7cc25d676c@www.novabbs.org>
 <6DghP.566840$EYNf.141529@fx11.iad> <vm5r00$2e9ha$1@dont-email.me>
 <nGuhP.275371$2xE6.65834@fx18.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 14 Jan 2025 16:50:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="9951024a6f598bbfa9f09d3a2343eba8";
	logging-data="2605968"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+5C1XoyAPK7Fj98yBVl3TAhsENMnYdmfo="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:G4KyO0WF0VThO1u6ckEXy8ocG3M=
In-Reply-To: <nGuhP.275371$2xE6.65834@fx18.iad>
Content-Language: en-GB
Bytes: 4709

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.)