[libvirt] [PATCH 2/2] util: Cast to 'long double' when calling isnan()
Andrea Bolognani
abologna at redhat.com
Tue Jan 3 13:27:07 UTC 2017
On Tue, 2017-01-03 at 13:54 +0100, Martin Kletzander wrote:
> On Mon, Jan 02, 2017 at 07:15:31PM +0100, Andrea Bolognani wrote:
> >
> > Clang 3.9 chokes when calling isnan() on a double variable:
> >
> > util/virxml.c:153:21: error: implicit conversion increases
> > floating-point precision: 'double' to
> > 'long double' [-Werror,-Wdouble-promotion]
> > (isnan(obj->floatval))) {
> > ~~~~~~~~~~~^~~~~~~~~
> > /usr/include/math.h:360:46: note: expanded from macro 'isnan'
> > # define isnan(x) __MATH_TG ((x), __isnan, (x))
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
> > /usr/include/math.h:295:16: note: expanded from macro '__MATH_TG'
> > : FUNC ## l ARGS)
> > ~~~~~~~~~ ^~~~
> >
> > Note how the wrong version of isnan() is being called: isnanl()
> > is for 'long double's, but obj->floatval is a double and a
> > suitable version should be called instead.
>
> I don't know where do you see that ^^. Good eyes, I guess =)
'FUNC ## l' turns into '__isnanl' when the macro is expanded,
and that's the isnan() variant to be used for 'long double's.
> > Cast the value to 'long double' to make the compiler happy.
> > ---
> > Clang seems to be tripping on the specific way the isnan()
> > macro is defined in recent glibc versions; more specifically,
> > if I replace the current definition in <math.h> with the one
> > that predates the introduction of the __MATH_TG() macro, I
> > can get the current code to compile. I was not able to find
> > anything wrong with the __MATH_TG() macro though.
>
> This sounds like a glibc <=> clang problem that we shoudn't introduce
> more complexity for. Also *I* don't see this error, for a change =)
Definitely, and I would SNACK any attempt to actually merge
this :)
It's just a dirty hack that I threw together in an attempt
to get the compiler to move on with the next error: its real
value is not in the code itself but in the commit message.
I believe we should look for existing Clang / glibc bugs
about this issue and, if none is found, file one along with
a minimal reproducer, which should be fairly easy to create.
--
Andrea Bolognani / Red Hat / Virtualization
More information about the libvir-list
mailing list