On 13 November 2015 at 15:52, Jonathan Wakely <jwak...@redhat.com> wrote:
> On 12/11/15 13:39 +0000, Jonathan Wakely wrote:
>>
>> 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...@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.
>
>
> That patch was wrong, the new macros in include/bits/c++config used
> "CSTDIO" instead of "STDIO" so it caused several tests to go from
> PASS to UNSUPPORTED, oops!
>
> This is the correct version, tested again more carefully, on
> powerpc64le-linux and powerpc-aix and x86_64-dragonfly.
>
> Committed to trunk.
>
Hi, this commit makes the GCC build to fail for targets using newlib
(I tested arm-none-eabi and aarch64-none-elf)
I'm seeing errors such as:
In file included from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/string:52:0,
from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/bits/locale_classes.h:40,
from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/bits/ios_base.h:41,
from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/ios:42,
from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/istream:38,
from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/sstream:38,
from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/complex:45,
from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/ccomplex:38,
from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/include/precompiled/stdc++.h:52:
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/bits/basic_string.h:
In function 'long long int std::__cxx11::stoll(const wstring&,
std::size_t*, int)':
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/bits/basic_string.h:5524:31:
error: 'wcstoll' is not a member of 'std'
{ return __gnu_cxx::__stoa(&std::wcstoll, "stoll", __str.c_str(),
^
Sorry I can't provide more details until Monday.
Christophe.
> Jennifer, thanks very much for making this happen.
