Re: implicit conversion loses floating-point precision

[Szabolcs Nagy <nsz@port70.net>]

* Vasyl Vavrychuk <vvavrychuk@gmail.com> [2014-07-05 22:06:23 +0300]:
> I checked that gcc 4.8 outputs the same warning.

i could only reproduce it with clang

> On Sat, Jul 5, 2014 at 3:43 PM, Rich Felker <dalias@libc.org> wrote:
> > On Sat, Jul 05, 2014 at 02:25:02PM +0300, Vasyl Vavrychuk wrote:
> > > /usr/local/opt/musl/include/math.h:94:23: note: expanded from macro
> > > '__ISREL_DEF'
> > > { return !isunordered(__x,__y) && __x op __y; }
> > >           ~~~~~~~~~~~~^~~~~~~~
> > > /usr/local/opt/musl/include/math.h:90:34: note: expanded from macro
> > > 'isunordered'
> > > #define isunordered(x,y) (isnan((x)) ? ((void)(y),1) : isnan((y)))
> > >                                  ^
> > > /usr/local/opt/musl/include/math.h:67:45: note: expanded from macro
> > 'isnan'
> > >         sizeof(x) == sizeof(float) ? (__FLOAT_BITS(x) & 0x7fffffff) >
> > > 0x7f800000 : \
> >
> > This seems to be the problem: it's issuing warnings for the conversion
> > to float in the branch that only happens if x already has type float.
> > So this seems to be a bug in clang.
> >
> > I don't see any way around it without turning off the warning on
> > clang's side. From musl's side, working around it seems to require
> > non-portable, compiler-specific logic in the public headers which is
> > not something we want, especially when the issue it's addressing is
> > only a warning being issued due to compiler bugs. If you see a way to
> > work around it without doing this, let me know.

it can be worked around with explicit conversion

  sizeof(x) == sizeof(float) ? __FLOAT_BITS((float)x) ...

but this is ugly so clang should fix the warning

seems to be yet another c++ism in clang, implicit conversions
are more dangerous there because of function overloading

> > Also, normally compilers suppress any warnings from system headers or

that too