ISO C99 support in <math.h> for C++98

Yaakov Selkowitz yselkowitz@cygwin.com
Wed Mar 23 20:34:00 GMT 2016


On 2016-03-23 13:21, Andre Vieira (lists) wrote:
> On 23/03/16 04:57, Yaakov Selkowitz wrote:
>> On 2016-03-22 13:53, Yaakov Selkowitz wrote:
>>> There's nothing wrong with -std=gnu++98.  The problem is with configure
>>> testing C99 macros with -std=c++98, which makes no sense and only works
>>> on glibc because they use -D_GNU_SOURCE indiscriminately with g++.  Fix
>>> those configure tests to use -std=c++11, as we did on Cygwin, and the
>>> features should be enabled.
>>
>> The attached patches for GCC enable _GLIBCXX_USE_C99 support with the
>> current feature test macros.
>>
> Im a bit confused by your patches. If I understand correctly, your
> changes will make the configure step that sets _GLIBCXX_USE_C99_MATH use
> -std=c++11 to compile the file it uses to test the existence of the C99
> math functions.

That was my intention; the comments did indicate a wish to switch to 
that anyway.

> I can see this will work for gcc-5, however with trunk there are two
> variants of _GLIBCXX_USE_C99_MATH: _GLIBCXX98_USE_C99_MATH and
> _GLIBCXX11_USE_C99_MATH.

Oh great...

> The first is set by the configuration step
> using -std=c++98 and the latter -std=c++11. For c++11 its all fine, but
> for c++98 the latest newlib changes introduce a difference between
> c++98, where the C99 math functions are not defined, and gnu++98, where
> they are. Here c++98 will work fine because when math.h will not define
> the C99 functions and cmath will not undefine them. However, with
> -std=gnu++98, math.h will define the C99 functions, but cmath, using
> _GLIBCXX98_USE_C99_MATH, will not undefine them.

The *only* reason the -std=c++98 tests work on Linux is that they use 
-D_GNU_SOURCE indiscriminately with C++, which essentially makes it 
-std=gnu++98.  That's PR51749 and really needs to be fixed properly.  As 
the point of the feature test macros overhaul is to be compatible with 
glibc, I'd prefer not using a newlib-specific hack, but to fix this 
properly for glibc as well.

While it makes NO SENSE WHATSOEVER for *pure* C++98 to rely upon C99, 
but II(now)UC TR1 *does*, and g++ doesn't really distinguish between 
C++98, C++03, or TR1.  Therefore, we can't use __cplusplus >= 201103L to 
enable C99; I think we're just going to have to change that to 
defined(__cplusplus).  Not a perfect solution, but sure a lot better 
than -D_GNU_SOURCE.

Patch forthcoming.

-- 
Yaakov



More information about the Newlib mailing list