[PATCH] Enable libstdc++ numeric conversions on Cygwin

Jonathan Wakely jwakely@redhat.com
Thu Nov 12 13:40:00 GMT 2015


On 12/11/15 11:40 +0000, Jonathan Wakely wrote:
>On 18/09/15 12:01 -0400, Jennifer Yao wrote:
>>Forgot to include the patch.
>>
>>On Fri, Sep 18, 2015 at 11:17 AM, Jennifer Yao
>><jenny.hyphen.fa@gmail.com> wrote:
>>>A number of functions in libstdc++ are guarded by the _GLIBCXX_USE_C99
>>>preprocessor macro, which is only defined on systems that pass all of
>>>the checks for a large set of C99 functions. Consequently, on systems
>>>which lack any of the required C99 facilities (e.g. Cygwin, which
>>>lacks some C99 complex math functions), the numeric conversion
>>>functions (std::stoi(), std::stol(), std::to_string(), etc.) are not
>>>defined—a rather silly outcome, as none of the numeric conversion
>>>functions are implemented using C99 math functions.
>>>
>>>This patch enables numeric conversion functions on the aforementioned
>>>systems by splitting the checks for C99 support and defining several
>>>new macros (_GLIBCXX_USE_C99_STDIO, _GLIBCXX_USE_C99_STDLIB, and
>>>_GLIBCXX_USE_C99_WCHAR), which replace the use of _GLIBCXX_USE_C99 in
>>>#if conditionals where appropriate.
>
>(Coming back to this now that Jennifer's copyright assignment is
>complete...)
>
>Splitting the _GLIBCXX_USE_C99 macro into more fine-grained macros for
>separate features is definitely the right direction.
>
>However your patch also changes the configure tests to use -std=c++0x
>(which should be -std=c++11, but that's a minor point). On an OS that
>only makes the C99 library available conditionally that will mean that
>configure determines that C99 library features are supported, but we
>will get errors if we try to use those features in C++03 parts of the
>library.
>
>I think a more complete solution is to have two sets of configure
>tests and two sets of macros, so that we define _GLIBCXX_USE_C99_STDIO
>when C99 stdio is available unconditionally, and define
>_GLIBCXX11_USE_C99_STDIO when it's available with -std=c++11.
>
>Then in the library code we can check _GLIBCXX_USE_C99_STDIO if we
>want to use C99 features in C++03 code, and check
>_GLIBCXX11_USE_C99_STDIO if we want to use the features in C++11 code.
>
>That should still solve the problem for the numeric conversion
>functions, because they are defined in C++11 and so would check
>_GLIBCXX11_USE_C99_STDIO, which will be defined for newlib.
>
>Other pieces of the library, such as locales, will use
>_GLIBCXX_USE_C99_STDIO and that might still be false for newlib (and
>for other strict C libraries like the Solaris and FreeBSD libc).
>
>I will make the changes to acinclude.m4 to duplicate the tests, so we
>test once with -std=c++98 and once with -std=c++11, and then change
>the library to check either _GLIBCXX_xxx or _GLIBCXX11_xxx as
>appropriate.

Here's a patch implementing my suggestion.

The major changes since Jennifer's original patch are in acinclude.m4,
to do the autoconf tests once with -std=c++98 and again with
-std=c++11, and in include/bits/c++config to define the
_GLIBCXX_USE_C99_XXX macros according to either _GLIBCXX98_USE_CXX_XXX
or _GLIBCXX11_USE_CXX_XXX, depending on the standard mode in effect
when the file is included.

Because those new definitions in bits/c++config are unconditional I
had to adjust a few #ifdef tests to use #if instead.

I also removed the changes to GLIBCXX_CHECK_C99_TR1, so that there are
no changes to the macros used for the TR1 library. As a follow-up
change I will add a test for <stdint.h> to GLIBCXX_ENABLE_C99 and
change several C++ headers to stop using the TR1 macros.

This passes all tests on powerpc64le-linux, I'll also try to test on
DragonFly and FreeBSD.

Does this look good to everyone?

One downside of this change is that we introduce some (hopefully safe)
ODR violations, where inline functions and templates that depend on
_GLIBCXX_USE_C99_FOO might now be defined differently in C++98 and
C++11 code. Previously they had the same definition, even though in
C++11 mode the value of the _GLIBCXX_USE_C99_FOO macro might have been
sub-optimal (i.e. the C99 features were usable, but the macro said
they weren't). Those ODR violatiosn could be avoided if needed, by
always using the _GLIBCXX98_USE_C99_FOO macro in code that can be
included from either C++98 or C++11. We could still use the
_GLIBCXX11_USE_C99_FOO macro in pure C++11 code (such as the numeric
conversion functions) and get most of the benefit of this change.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 58290 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20151112/9222d346/attachment.bin>


More information about the Gcc-patches mailing list