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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list