[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