From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 75568 invoked by alias); 21 Nov 2017 11:33: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 75543 invoked by uid 89); 21 Nov 2017 11:33:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=rpm, proprietary, HContent-Transfer-Encoding:8bit X-Spam-User: qpsmtpd, 3 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Nov 2017 11:33:24 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2F38864D8C; Tue, 21 Nov 2017 11:33:23 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-116-45.ams2.redhat.com [10.36.116.45]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9DB17171AE; Tue, 21 Nov 2017 11:33:20 +0000 (UTC) Subject: Re: [PATCH libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values To: Ed Smith-Rowland <3dw4rd@verizon.net>, Jonathan Wakely Cc: "libstdc++@gcc.gnu.org" , gcc-patches , Jonathan Wakely , redi@gcc.gnu.org References: <755dc780-d676-65ca-ba9b-81a4bf80a3f3@verizon.net> <20171117205429.GA31922@redhat.com> From: Florian Weimer Message-ID: <8c63977a-6d6c-44b9-876b-5d01bd38e95b@redhat.com> Date: Tue, 21 Nov 2017 11:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg01877.txt.bz2 On 11/18/2017 05:49 PM, Ed Smith-Rowland wrote: > I feel that distros are likely to pick up gcc-7 soon and I'd like to do > *something*.  This would be something of a transition path. Historically, in glibc, we would have used symbol versioning for this, so that existing binaries retain the old behavior. The downside is that blind recompilation will give you the change in behavior, so it essentially benefits proprietary software vendors only, which is why I think it's usually not appropriate to do this because either you want the fix for all applications, recompiled or not, or you don't. In addition, in Fedora and downstream, we cannot backport new symbol versions unless the symbol version is unique to the feature/bug fix being added, due to the way RPM dependencies are generated. Thanks, Florian