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