[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ace1447c-d846-3ea7-7936-2de69c21d83@esi.com.au>
Date: Wed, 26 Jun 2024 08:55:08 +1000 (AEST)
From: Damian McGuckin <damianm@....com.au>
To: musl@...ts.openwall.com
Subject: Re: roundf() (and round(), and ...)
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.
- Damian
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.
