Date: Mon, 29 Jul 2013 18:31:22 +0300 From: Pasi Parviainen <pasi.parviainen@iki.fi> To: Raphael Kubo da Costa <rakuco@FreeBSD.org> Cc: Scot Hetzel <swhetzel@gmail.com>, "freebsd-standards@FreeBSD.org" <freebsd-standards@FreeBSD.org>, "freebsd-toolchain@FreeBSD.org" <freebsd-toolchain@FreeBSD.org>, Garrett Wollman <wollman@csail.mit.edu>, FreeBSD Current <freebsd-current@FreeBSD.org>, Tijl Coosemans <tijl@FreeBSD.org>, "O. Hartmann" <ohartman@zedat.fu-berlin.de> Subject: Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity Message-ID: <51F68ACA.8030500@iki.fi> In-Reply-To: <83zjt5mwri.fsf@FreeBSD.org> References: <20130710155809.0f589c22@thor.walstatt.dyndns.org> <CD51F125-AE9E-4461-916D-CF583002B47D@FreeBSD.org> <20130710183315.725dfde0@thor.walstatt.dyndns.org> <C8C94CF2-7D5A-471B-AD63-8E961AED6274@FreeBSD.org> <20130710203200.5359fd18@thor.walstatt.dyndns.org> <51DDC04B.6040209@FreeBSD.org> <20957.49978.73666.392417@khavrinen.csail.mit.edu> <20130711130043.R920@besplex.bde.org> <FD768A6B-8B72-44A1-BC1C-14FF44CB4643@FreeBSD.org> <20130711202908.L84170@besplex.bde.org> <C00DFA94-6182-4334-9C90-8012E576E475@FreeBSD.org> <CACdU%2Bf9RmwxSiMEjOwSXHtnDwKk4xY8fmA3aBE5mzrVUkrc1Nw@mail.gmail.com> <CACdU%2Bf-LKsHsPayUYAT-cip91O=CfQg2aJ1BKC5PRd6G9Kf28w@mail.gmail.com> <20130712234749.5afa3c9b@thor.walstatt.dyndns.org> <9B0A6D14-640E-4ADD-8E58-0B7867C7C674@FreeBSD.org> <51E145CC.8080900@iki.fi> <861u6iv0ih.fsf@orwell.Elisa> <BD6EC81A-C02D-4907-80D4-BEC141E9EA10@FreeBSD.org> <83zjt5mwri.fsf@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29.7.2013 14:27, Raphael Kubo da Costa wrote:
> David Chisnall <theraven@FreeBSD.org> writes:
>
>> On 28 Jul 2013, at 22:27, Raphael Kubo da Costa <rakuco@freebsd.org> wrote:
>>
>>> This seems to have been committed in r253321, and broke some code that
>>> was working with r253320; namely, some code in x11/kde4-workspace
>>> includes math.h and calls isnan() with a const double.
>>
>> Please provide a test case. Specifically, I need to know what
>> language dialect this is using, because I have tested including math.h
>> and calling isnan(double) with c89, gnu89, c99, c11, c++03 and c++11
>> on gcc (for the modes that it supports) and clang.
>
> I get the following results with and without -std=c++11 and/or
> -stdlib=libc++:
>
> % cat isnan.cc
> #include <math.h>
> int main() {
> const double d = 42.0;
> return isnan(d) ? 1 : 0;
> }
>
> % clang++ isnan.cc
> isnan.cc:4:10: error: controlling expression type 'const double' not
> compatible with any generic association type
> return isnan(d) ? 1 : 0;
> ^~~~~~~~
> /usr/include/math.h:109:2: note: expanded from macro 'isnan'
> __fp_type_select(x, __inline_isnanf, __inline_isnan,
> __inline_isnanl)
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /usr/include/math.h:86:49: note: expanded from macro '__fp_type_select'
> #define __fp_type_select(x, f, d, ld) _Generic((0,(x)),
> \
> ^~~~~
> 1 error generated.
>
In the first place C++ code should be using cmath instead of math.h.
That said, this is a result of just an another wonderful little
difference between C and C++. C standard explicitly states that comma
operator does not yield an lvalue but in C++ it can if the right most
operand is an lvalue. If C++ compatibility is desired then unary +
operator (e.g. _Generic(+(x),...) could be used for the same effect,
only downside with this is that the integer arguments are promoted, but
that doesn't matter in this case.
Pasi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51F68ACA.8030500>