[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGj4m+5WwCM=aZgK-CaaKLGFB70pWHzMx7tbRtQ9C=t-6nZ44g@mail.gmail.com>
Date: Sat, 5 Jul 2014 22:06:23 +0300
From: Vasyl Vavrychuk <vvavrychuk@...il.com>
To: musl@...ts.openwall.com
Subject: Re: implicit conversion loses floating-point precision
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@...c.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
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
