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

[Andre Vieira (lists)]

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.

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. 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.

I opened a bugzilla ticket PR70379 to track this. I also spoke to
jwakely on the gcc IRC chat and he gave me the tip to look at the
"DYNAMIC" macros in libstdc++-v3/config/os/bsd/freebsd/os_defines.h.
This lead me to try to make cmath also undef the C99 math functions if a
new macro '_GLIBCXX_USE_C99_MATH_DYNAMIC' is defined. Then in newlib, we
could define this macro if the C99 math functions are used.

I'll let you know how that went and if there are no objections Ill also
start working on patches for gcc and newlib to make this work again on
trunk, we can then re-use the same approach for gcc-5/embedded-5-branch.

Thanks!

Cheers,
Andre