RE: [PATCH] Remove __isinf uses that rely on signed return value

["Wilco Dijkstra" <wdijkstr at arm dot com>]

> Joseph Myers wrote: 
> On Wed, 3 Jun 2015, Wilco Dijkstra wrote:
> 
> > > Joseph Myers wrote:
> > > On Tue, 2 Jun 2015, Wilco Dijkstra wrote:
> > >
> > > > The printf code contains a few uses of __isinf where the sign is used -
> > > > replace these with separate isinf and signbit.
> > >
> > > Why?  Isn't the point of glibc's isinf returning a signed value that you
> > > can do such combined operations?
> >
> > We discussed this a while back (and I thought it was agreed on going forward
> > like this) - to recap, it is not required by any standard (so no standard
> 
> I don't recall any such discussion or agreement.  The discussion in bug
> 15367 is on the basis of using __builtin_isinf_sign to implement the
> header macro, not of changing the requirements and sometimes using
> __builtin_isinf.

Well it was a while back. However the GCC built-ins need further optimization
and fixes so just using the builtins is not a good fix either...

> > compliant software may rely on this GLIBC specific behaviour), and is
> > actually incompatible with C++ which requires a boolean to be returned.
> 
> C++ is the responsibility of libstdc++ (and defines overloaded functions,
> not type-generic macros; libstdc++ needs to override things done in the C
> header anyway).
> 
> > So the idea is to only support the old behaviour in GNUC mode for backwards
> > compatibility, but not in C99/C++.
> 
> glibc is built with _GNU_SOURCE and can freely use all GNU features
> (subject to link-time namespace issues).  I see no need to change the
> interface to this macro in glibc.  Presumably the aim should be to make
> the GCC __builtin_isinf / __builtin_isinf_sign at least as efficient as
> the out-of-line functions, and safe for all inputs, make the isinf macro
> use __builtin_isinf_sign, and make GCC optimize __builtin_isinf_sign calls
> so it's as efficient as __builtin_isinf if the sign isn't used, and as
> efficient as __builtin_isinf + __builtin_signbit if the sign is used.

In principle GLIBC could continue to use this feature internally, but do 
you have any objections to removing all internal uses like my patch does?

In terms of interface, why do you think it is useful to continue a non-standard
interface indefinitely rather than making it GNUC specific? Other than backwards
compatibility there seems to be no compelling reason to keep it.

Note I am also planning to remove all internal uses of __isinf_ns and replace
them with isinf - no reason to keep using this non-standard interface either!

Yes it would be possible to expand isinf as:

(__isinf_ns (x) ? (signbit (x) ? -1 : 1) : 0)

This should make if (isinf (x)) as efficient as if (__isinf_ns (x)), however if 
the result is assigned to a variable then it would always have additional overhead.
This is obvious if the sign is not used, but if the sign is used it would still
not be as efficient as separate isinf and signbit calls.

Wilco