This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]