From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74061 invoked by alias); 12 Nov 2015 22:56:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 73996 invoked by uid 89); 12 Nov 2015 22:56:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: smtp.fgznet.ch Received: from smtp.fgznet.ch (HELO smtp.fgznet.ch) (157.161.14.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 12 Nov 2015 22:56:23 +0000 Received: from [192.168.225.14] (dhclient-91-190-14-19.flashcable.ch [91.190.14.19]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by fgznet.ch (Postfix) with ESMTPS id 2805FCF0D7; Thu, 12 Nov 2015 23:56:20 +0100 (CET) Subject: Re: [PATCH] Enable libstdc++ numeric conversions on Cygwin To: Jonathan Wakely , Jennifer Yao References: <20151112114049.GY2937@redhat.com> <20151112133947.GA2937@redhat.com> Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org From: Andreas Tobler Message-ID: <56451913.6090206@fgznet.ch> Date: Thu, 12 Nov 2015 22:56:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151112133947.GA2937@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg01615.txt.bz2 On 12.11.15 14:39, 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 >>> 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 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. > I have successfully tested this patch on FreeBSD -CURRENT and also on CentOS7.1 (x86_64). I had the previous version installed for a longer time and I see no regressions compared with it. N.B: I didn't apply the follow up patch since you mentioned it does not work. So, for me it looks good and I'm very happy to see this coming in. Thank you all!! Regards, Andreas