[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240625233742.GJ10433@brightrain.aerifal.cx>
Date: Tue, 25 Jun 2024 19:37:42 -0400
From: Rich Felker <dalias@...c.org>
To: Damian McGuckin <damianm@....com.au>
Cc: musl@...ts.openwall.com
Subject: Re: roundf() (and round(), and ...)
On Wed, Jun 26, 2024 at 08:55:08AM +1000, Damian McGuckin wrote:
> On Tue, 25 Jun 2024, Markus Wichmann wrote:
>
> >If GCC is working according to the documentation, then not inside
> >of musl at the moment. These inlinings happen when a builtin
> >instrinsic is lowered into an assembler instruction, and by
> >default, fabs* is recognized as a builtin. But not when building
> >musl, because musl builds with -ffreestanding, which includes
> >-fno-builtin.
>
> As a general rule, I think that is a very wise decison.
>
> >Rich has stated he wants to work around that with an
> >implementation-internal header file that defines macros such as
>
> >#define fabs(x) __builtin_fabs(x)
>
> With IEEE 754 (in 5.5.1) defining all of copy, negate, abs (and
> copysign) as sign-bit operations, i.e. they are not just recommended
> operatons, I think this is a smart move, at least for the absolute
> value and sign copy
> functionality.
I don't see how that's relevant. The external function call versions
are obligated to follow the IEEE rules too, which we do, and
__builtin_fabs does not imply a contract that the compiler can expand
fabs inline, just an allowance that it can know this means "the
standard fabs function semantics" to inline that if it wants, or emit
an external call. So doing this will purely be an optimization, no
semantic difference.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
