From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12479 invoked by alias); 26 May 2017 11:52:52 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 12315 invoked by uid 89); 26 May 2017 11:52:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=mitigate, defect, H*M:c9ba X-HELO: mail-wr0-f178.google.com Received: from mail-wr0-f178.google.com (HELO mail-wr0-f178.google.com) (209.85.128.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 26 May 2017 11:52:31 +0000 Received: by mail-wr0-f178.google.com with SMTP id j27so607382wre.1 for ; Fri, 26 May 2017 04:52:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=mUMMXyhTgZ8qqlMYtH2a7+NTZPJiuID+6CvlRVj1jZo=; b=HPoJhxNN8oc9toNgg8VvajBCV3G9bGvTMRSR2QZT4rGIivmB8xg+PTDovZyVQELWVD 5osmWgDx1sAhZY5uW4Yk3H3tZdRy/GzkfC0Oqe6pKp20PRQ24dkEcoIBVL2OlbpxR4DT v5IqWvXlVb39QrX4wzGUnK2Kzsu/PiMJApU4tN1i5VblRtyE1KP/QNlScORI/hTaUKSZ e80cVWDWprU+MxNc+XD/gm8KuzJcbwFu+FHWU+qeHrHdl+5pRTZEt0ORdOfWZMAD/IpN Eo/mpHZ/zG1xFJOfMY3E9tVZP4vxcOanLma1Pn4QTkSdHE2RnmGoHeUS8Waj21LkXOyr hu1Q== X-Gm-Message-State: AODbwcBFctuaLctCPRwdwqXG/XJ3atFlnGhf8pZj5jQguTra3mvsneA7 EfUIIy/hdmUKGU/phRqvuw== X-Received: by 10.223.175.46 with SMTP id z43mr1656710wrc.84.1495799550369; Fri, 26 May 2017 04:52:30 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id 92sm489773wra.0.2017.05.26.04.52.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 May 2017 04:52:28 -0700 (PDT) Subject: Re: GDB 7.99.91 MinGW compilation error in cli-script.c To: Eli Zaretskii References: <20170504194442.63AAF60B72@joel.gnat.com> <83o9v3cs25.fsf@gnu.org> <91d9fc6cc7c07674a0b5cd02e7b1502b@polymtl.ca> <8360h38r1r.fsf@gnu.org> <20170517143136.mdnstf2u2jiydvnd@adacore.com> <83fug35v70.fsf@gnu.org> <83y3tt2ow0.fsf@gnu.org> <83vaox2j0w.fsf@gnu.org> <7017128a-7b51-5436-657b-58807d04eb02@redhat.com> <83vaouns1q.fsf@gnu.org> <837f18ohr2.fsf@gnu.org> <54594002-5d70-9ff8-c481-0cbfc8c68c7b@redhat.com> <83fufvm0ro.fsf@gnu.org> <436bb773-a9b2-6c32-2b9c-7d3a6297d634@redhat.com> <83shjsjbib.fsf@gnu.org> Cc: brobecker@adacore.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <1e36b12c-3cd5-8ea2-c9ba-f97fa8085c66@redhat.com> Date: Fri, 26 May 2017 11:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <83shjsjbib.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00558.txt.bz2 On 05/26/2017 08:57 AM, Eli Zaretskii wrote: >> Cc: brobecker@adacore.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Thu, 25 May 2017 11:05:00 +0100 >> >>>> I'm surprised mingw does this, because that's a libstdc++ >>>> internal symbol... >>> >>> I'm guessing that was done because releases of MinGW runtime and the >>> MinGW port of GCC are not in sync. So people who have a GCC >>> installation and upgrade to a later MinGW runtime expect to have this >>> problem solved, but the way you seem to assume tjis to happen is by >>> them having to build an updated GCC or wait for an update of the GCC >>> distribution. >> >> Your use of "have to wait" above doesn't make sense to me, to be >> honest. mingw.org maintainers chose to update the runtime and not >> the compiler. It's their choice. Users have to update some component to >> fix this, but the decision that the component that needs updating is >> the runtime is mingw.org maintainer's. It would have been equally possible to >> provide an updated GCC release of the exact same GCC version / vintage >> that defined _GLIBCXX_USE_C99 itself (or some other similar localized >> hack or even a backport of the proper fix upstream) instead of >> defining a libstdc++ internal symbol in the runtime and potentially >> causing trouble when/if folks update to newer GCCs that >> treat _GLIBCXX_USE_C99 differently, exactly because, as you say, >> the runtime and the compiler are not released in sync. > > I think there's some misunderstanding here. Maybe. > The MinGW runtime needed > to be updated in any case, because the root cause of not defining > _GLIBCXX_USE_C99 for MinGW was a deficiency in the MinGW runtime: a > specific stdio function in the MS runtime wasn't behaving in > ANSI-compliant way, and needed a replacement for it to be added to > MinGW. My understanding of the issue is that libstdc++ had a too-coarse way to tell whether the runtime supports C99, and that ended up disabling std::to_string because some unrelated (to std::to_string) bits of C99 support are missing in mingw.org. Specifically, wide string functions are not really necessary for std::to_string. Having non-conforming C99 math-related bits also disabled std::to_string (see bug I pointed at), again because _GLIBCXX_USE_C99 is too coarse-grained. So forcing _GLIBCXX_USE_C99 exposes std::to_string, but also exposes other C99 broken / non-conforming bits. > The _GLIBCXX_USE_C99 macro was undefined in the libstdc++ > headers because of that problem, and the decision whether to define it > is made at libstdc++ build time, based on the MinGW runtime that was > present at that time. Yes. > > Once that change in the MinGW runtime was made, there were two > possible ways of fixing the to_string problem in libstdc++: > > . build and release a new distribution of GCC, and tell everyone > that they must upgrade their GCC, together with MinGW runtime; or > > . force _GLIBCXX_USE_C99 to be defined in the MinGW runtime headers > > The MinGW maintainers decided to do the latter, most probably because > it is easier on both users and the maintainers. I don't think the fix on the GCC side really requires a mingw runtime update. I may well be wrong, of course. >>> mingw.org's MinGW currently doesn't offer GCC newer than 5.3.0, so >>> this solution is not yet available to MinGW users. Maybe soon it will >>> be. >> >> The point was that the compiler fix will make std::to_string available >> even when _GLIBCXX_USE_C99 ends up not defined, AFAICS. Meaning that with >> newer compilers we'll replace std::to_string when it's not necessary, >> AFAICS, given: >> >> +#ifdef __MINGW32__ >> +# include <_mingw.h> >> +# ifndef _GLIBCXX_USE_C99 >> +# undef REPLACE_TO_STRING >> +# define REPLACE_TO_STRING 1 >> +# endif >> +#endif >> >> >From the ChangeLog entry seen on that bugzilla url, I'd think that >> skipping the replacement when GLIBCXX_USE_C99_STDIO is defined >> would work. > > I'm okay with adding the newer symbols to the patch I already > installed, if that's what you want. the latest GCC that's currently > available for MinGW is 5.3.0, where these newer symbols don't yet > appear. > I cloned the current mingw sources to see what's been done over there, and here's what's there now (on the 5.0-active branch): #if _ISOC99_SOURCE && __cplusplus >= 201103L && __GNUC__ < 6 /* Due to a configuration defect in GCC versions prior to GCC-6, when * compiling C++11 code, the ISO-C99 functions may not be incorporated * into the appropriate namespace(s); we may be able to mitigate this, * by ensuring that these GCC configuration macros are defined. */ # define _GLIBCXX_USE_C99 1 # define _GLIBCXX_HAVE_WCSTOF 1 #endif I would have helped a lot if I had been shown this. Note the "__GNUC__ < 6" check. So with newer compilers (yes, there's no official binaries, but other people can and do build their own compilers) _GLIBCXX_USE_C99 won't be hacked in. So I think we'll define the replacement replacement when we needn't. But in any case, I'll just ignore that. If you're happy with the gdb fix in place now, I'm happy enough with it too. Thanks, Pedro Alves