From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21029 invoked by alias); 25 May 2017 10:05:02 -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 21009 invoked by uid 89); 25 May 2017 10:05:01 -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,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=vintage, notices, offer X-HELO: mail-wm0-f47.google.com Received: from mail-wm0-f47.google.com (HELO mail-wm0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 25 May 2017 10:05:00 +0000 Received: by mail-wm0-f47.google.com with SMTP id 7so85068857wmo.1 for ; Thu, 25 May 2017 03:05:03 -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=pDwGpO+ZyOoOKX1Z18LyBZPnpJWLZRGrbD0W/et2fzk=; b=mtT2DXkuKWTxS0rfRD1hX2gDSssQt4x4TWRDWBm4xG9xCRtJn4YUvMGN/c0aVIyDya LKnGWm2ZP+x9XoRbYB5fCdzcz0ixz+NMjf745j31+hWq8x29yJbSQXEgAcW5l0RY29LY taRI/LVmLujGxeiF2rpFwN6lOjSK508kLt+Wss+XsCpZ4Tr1pTmVBDN+eDxyA68I2SSL CDKwIc8kmln4e+iZ0S91VG+tRd2KCmjCoXoB0w1lLf/JZk3fCYg8zKPZqDb+4Mog70He SB9etNJeYVtuoDQVOAach1qLdRJrR8jBuYQtia1OhwyMVRt7/LENcbSqq23bYv6oReIO 0J0w== X-Gm-Message-State: AODbwcCbjjQdDYbDW5t31agKI44dpPH72AQUoZ2Wiu5BfozcYmQ14+lu bVGvnr8MGwX8zQPi3aUHcg== X-Received: by 10.28.154.86 with SMTP id c83mr8850033wme.94.1495706701871; Thu, 25 May 2017 03:05:01 -0700 (PDT) Received: from [192.168.0.102] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id m191sm8749635wmg.30.2017.05.25.03.05.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 03:05:01 -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> Cc: brobecker@adacore.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org From: Pedro Alves Message-ID: <436bb773-a9b2-6c32-2b9c-7d3a6297d634@redhat.com> Date: Thu, 25 May 2017 10:05: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: <83fufvm0ro.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-05/txt/msg00534.txt.bz2 On 05/24/2017 03:44 AM, Eli Zaretskii wrote: >> Cc: brobecker@adacore.com, simon.marchi@polymtl.ca, gdb-patches@sourceware.org >> From: Pedro Alves >> Date: Tue, 23 May 2017 10:53:47 +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. > >> Please also take a look at the fix for: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393 >> >> which suggests to me that newer compilers against older mingw >> might actually be fixed, independently of the _GLIBCXX_USE_C99 hack? > > 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. But guess we'll just revisit when/if someone ever notices [to_string replaced when it didn't need to], or when we stop supporting compilers that had this broken, whichever comes first. I'll go look at your newer patch. Thanks, Pedro Alves