[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140705124358.GJ179@brightrain.aerifal.cx>
Date: Sat, 5 Jul 2014 08:43:58 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: implicit conversion loses floating-point precision
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
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.
