From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120617 invoked by alias); 6 Dec 2016 00:31:13 -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 120604 invoked by uid 89); 6 Dec 2016 00:31:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,LIKELY_SPAM_BODY,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=no version=3.3.2 spammy=arrangements, Steven, Munroe, munroe X-HELO: relay1.mentorg.com Date: Tue, 06 Dec 2016 00:31:00 -0000 From: Joseph Myers To: Steven Munroe CC: "Gabriel F. T. Gomes" , Subject: Re: [PATCH 3/8] float128: Add wrappers for IEEE functions. In-Reply-To: <1480978305.13834.14.camel@oc7878010663> Message-ID: References: <1478716859-3246-1-git-send-email-gftg@linux.vnet.ibm.com> <1478716859-3246-4-git-send-email-gftg@linux.vnet.ibm.com> <20161205144754.4c0c7c13@keller.br.ibm.com> <1480978305.13834.14.camel@oc7878010663> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2016-12/txt/msg00121.txt.bz2 On Mon, 5 Dec 2016, Steven Munroe wrote: > Are these changes really necessary at this time? The question is what is the right, most maintainable way to add support for a new floating-point format and associated type. Given that support for further formats / types may well be added in future (_Float16 being the most obvious possibility; WG14 has also expressed support for considering adding short float to C2x, which would likely alias _Float16 functions when not aliasing float ones), minimising the number of places where something needs repeating for each new type is clearly an important consideration. Since we've also desired for a long time to obsolete support for _LIB_VERSION and matherr, avoiding support for those in new interfaces is also clearly desirable - any ABI added needs to be supported long-term, so we need to be careful that it's the right ABI. This indicates using new-style wrappers for the new types, while the previous point indicates making those wrappers type-generic. Then, the question is simply how to use the type-generic wrappers for new types without affecting binary compatibility for the old types, which is the subject of the present discussion. Note that I'm not saying the whole deprecation needs to go in at this point. Just that the desire for a future deprecation provides useful guidance on the arrangements for the new wrappers. Since I was warning over a year ago about the complexity of supporting a new type (I expected 50 to 100 patches), and included matherr / wrappers in the issues to consider, I don't think any of this should be a surprise. I think all the development so far that Paul and others have worked on has been perfectly consistent with what I advised - adding support for the new type is perfectly feasible, substantial progress has been made, various design details have changed over time but the overall outline is as expected, the complexity of the changes means it's usual for a patch series to require several reviews and revisions and possibly design changes before it's ready to go in (but the numbers of revisions involved are small compared to many I've seen in the Linux kernel context where a patch series can have dozens of revisions and take years to get in). -- Joseph S. Myers joseph@codesourcery.com