Re: implicit conversion loses floating-point precision

[Vasyl Vavrychuk <vvavrychuk@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2604 bytes --]

Hi,

I checked that gcc 4.8 outputs the same warning.

But thanks for isystem. I am fully okay with that.

Regards,
Vasyl


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:
> > Hi,
> >
> > For musl 1.1.3 building with libc++ and clang I get
> >
> > /usr/local/opt/musl/include/math.h:97:1: error: implicit conversion loses
> > floating-point precision: 'double_t' (aka 'double') to 'float'
> > [-Werror,-Wconversion]
>
> This warning is bogus. If the compiler were behaving correctly, x=y+z,
> where x, y, and z all have type float or all have type double, would
> have to produce this warning on archs (like i386) with
> FLT_EVAL_METHOD==2, but I doubt it does.
>
> Unfortunately, it doesn't seem to be able to separate this bogus
> behavior from the other aspects of -Wconversion, which, while I don't
> agree with, I understand that many projects may be using this option.
>
> > __ISREL_DEF(less, <, double_t)
> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > /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.
>
> Also, normally compilers suppress any warnings from system headers or
> code expanded from system headers, so perhaps clang isn't identifying
> musl's headers as being system headers. If you're trying to use a
> clang that wasn't built to target musl, by suppressing the default
> header and library directories, this might be the cause; you need to
> use -isystem rather than -I in that case.
>
> Hope this helps!
>
> Rich
>

[-- Attachment #2: Type: text/html, Size: 3439 bytes --]