From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19421 invoked by alias); 30 Aug 2016 17:42:56 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 19406 invoked by uid 89); 30 Aug 2016 17:42:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=discussions, quirks, wrappers, _lib_version X-HELO: relay1.mentorg.com Date: Tue, 30 Aug 2016 17:42:00 -0000 From: Joseph Myers To: "Paul E. Murphy" CC: "libc-alpha@sourceware.org" Subject: Re: [PATCHv3 1/4] ldbl-128: Rename 'long double' to '_Float128' In-Reply-To: <4334e328-d6ed-5efe-0dc2-832bb54e5498@linux.vnet.ibm.com> Message-ID: References: <4334e328-d6ed-5efe-0dc2-832bb54e5498@linux.vnet.ibm.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-08/txt/msg00908.txt.bz2 On Tue, 30 Aug 2016, Paul E. Murphy wrote: > I do not plan on working on the matherr/_LIB_VERSION > deprecation until after we work through _Float128. I > don't think there is enough time in this release cycle > to do it. There are too many machine specific quirks. There are four months left in this release cycle before freeze. matherr/_LIB_VERSION deprecation naturally splits into turning symbols into compat symbols / updating documentation, and introducing new wrappers that don't use _LIB_VERSION / __kernel_standard*. It's the latter that involves machine-specific issues (where machines have their own versions of wrappers), but can also be split to keep the machine-independent parts of the change separate from the machine-specific ones. (Actually, I'd also expect preliminary patches to be needed for cases where the __ieee754_* functions being wrapped do not return the correct values for special cases but this is currently hidden by the wrappers.) > Though, as noted in earlier discussions, _Float128 > will not support matherr/_LIB_VERSION. Well, the patches will need to include appropriate rationale for the approach taken being the right design (which I'd have thought meant new type-generic wrappers that are also used for other types for static linking / absence of symbol version compatibility with old releases, but it's open to you to argue the merits of some other design in the patch submissions). -- Joseph S. Myers joseph@codesourcery.com