[Bug libstdc++/58625] std::signbit always converts to double

["olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58625

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #1)
> Weird that nobody noticed for so much time.

Probably not everybody is practicing the neurotic habit of checking the asm
output for every bit and piece ;)

(In reply to Paolo Carlini from comment #2)
> Well, now I see this can be certainly a correctness issue, for eg very small
> negative long doubles. Thus I think we should certainly do the change anyway
> for 4.9. For c_std I'm afraid we have to add overloads (I think, essentially
> copy over the corresponding bits of c_global without constexpr). Can you
> send a patch to the libstdc++-v3 mailing list? And, please, double check
> isnan and isinf. Thanks!

Yes, I can do that.  But how to check this in a target independent way?  Tree
dump and check whether the correct builtin names appear?

There's another place in file libstdc++-v3/include/c_std/cmath:

  template<typename _Tp>
    inline typename __gnu_cxx::__enable_if<__is_arithmetic<_Tp>::__value,
                       int>::__type
    signbit(_Tp __f)
    {
      typedef typename __gnu_cxx::__promote<_Tp>::__type __type;
      return __builtin_signbit(__type(__f));
    }

I guess that this is supposed to be used when C++ code pulls in <math.h> and
uses the C macro signbit instead of std::signbit.  It doesn't happen on my SH /
newlib cross config -- I get something like ((sizeof(x) == sizeof(float)) ?
__signbitf(x) : __signbitd(x)).  But if on some config it does happen, then the
problem would be the same, thus requiring signbit (and friends) overloads as
it's done for sqrt etc in the same file, right?