[Mesa-dev] [PATCH] nv50/ra: `isinf()` is in namespace `std` since C++11

Jose Fonseca jfonseca at vmware.com
Thu Mar 24 23:36:10 UTC 2016


On 24/03/16 22:07, Ilia Mirkin wrote:
> On Sat, Mar 19, 2016 at 6:30 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 19/03/16 22:25, Ilia Mirkin wrote:
>>>
>>> On Sat, Mar 19, 2016 at 6:23 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>>>>
>>>> On 18/03/16 04:00, Ilia Mirkin wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Mar 17, 2016 8:27 PM, "Matt Turner" <mattst88 at gmail.com
>>>>> <mailto:mattst88 at gmail.com>> wrote:
>>>>>    >
>>>>>    > On Thu, Mar 17, 2016 at 5:17 PM, Pierre Moreau
>>>>> <pierre.morrow at free.fr
>>>>> <mailto:pierre.morrow at free.fr>> wrote:
>>>>>    > > This fixes a compile error while building Nouveau with C++11
>>>>> enabled (and
>>>>>    > > glibc >= 2.23). This happens if SWR is enabled, as it forces
>>>>> C++11.
>>>>>    >
>>>>>    > That seems bad, right?
>>>>>    >
>>>>>    > Enabling OpenSWR should affect how any other drivers are built. Why
>>>>>    > does this happen?
>>>>>
>>>>> Yeah, the fix here is to fix the build not to add random unrelated
>>>>> options from one driver when building another.
>>>>
>>>>
>>>>
>>>> Although I agree in principle, that drivers should not interfere with
>>>> others
>>>> build,  C++14 will soon be the default [1].
>>>>
>>>> So, in this particular case, it seems a missed opportunity not to try to
>>>> fix
>>>> this generically.
>>>>
>>>>
>>>> What about adding to include/c99_math.h something like
>>>>
>>>> #if __cplusplus >= 201103L
>>>>      using std::isinf;
>>>> #endif
>>>
>>>
>>> Why is isinf() becoming unavailable by the way? I don't think anyone's
>>> given a clear answer on that. At least I haven't heard one.
>>
>>
>> It's unavoidable.
>>
>> On C99 isinf is a macro.
>>
>> On C++11 isinf is an function inside std namespace.
>>
>> You can't have a macro inside a C++ namespace -- macros have no namespaces.
>>
>> So, even if you `#include <math.h>` instead of `#include <cmath>`, the
>> math.h must not `#define isinf` so that C-prepposeccor doesn't expan
>> `std::isinf` to invalid code.
>
> OK, so then we should drop this logic in whereever we define isinf
> (iirc there's a definition for some platform that doesn't have it) or
> in c99_math.h as Matt suggests.

No, there's no isinf definition anywhere anymore.

But as I said c99_math.h sounds a good place for it.

Jose



More information about the mesa-dev mailing list