This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH][AArch64] Add inlines for signbit


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]