This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
RE: [PATCH][AArch64] Add inlines for signbit
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Wilco Dijkstra <wdijkstr at arm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 27 Apr 2015 17:09:35 +0000
- Subject: RE: [PATCH][AArch64] Add inlines for signbit
- Authentication-results: sourceware.org; auth=none
- References: <000001d07775$77c71880$67554980$ at com> <alpine dot DEB dot 2 dot 10 dot 1504241724020 dot 30193 at digraph dot polyomino dot org dot uk> <000001d080d7$830485a0$890d90e0$ at com>
On Mon, 27 Apr 2015, Wilco Dijkstra wrote:
> > Joseph Myers wrote:
> > On Wed, 15 Apr 2015, Wilco Dijkstra wrote:
> >
> > > Is there a reason this couldn't be done by default in math.h similar to isgreater (unlike
> > > __builtin_isinf et al, GCC implements signbit efficiently and correctly).
> >
> > It is, however, not type-generic in GCC
> > <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36757>, so you'd still need
> > to have a macro expansion checking sizeof.
>
> Yes indeed. However the issue is how to deal with the targets that currently
> define inlines. Would it be reasonable just to leave them and add a signbit
> expansion for GCC >= 3.0 that directly uses the builtins?
> (if we define __signbit(f/l) to be __builtin_signbit(f/l), things may go
> wrong as the various mathinlines don't do an undef first).
I'd think defining __signbit to __builtin_signbit, etc., would be
appropriate (with conditionals in the mathinline.h files to disable their
local definitions for GCC versions where __builtin_signbit works and is at
least as good for that architecture). It would also cover cases within
glibc that directly use the __signbit etc. names (although arguably those
should move to using the type-generic macros; likewise direct uses of e.g.
__finite, __isnan).
--
Joseph S. Myers
joseph@codesourcery.com