From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28716 invoked by alias); 6 Dec 2016 02:39:26 -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 28690 invoked by uid 89); 6 Dec 2016 02:39:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,LIKELY_SPAM_BODY,RCVD_IN_DNSWL_LOW,RCVD_IN_SEMBACKSCATTER autolearn=no version=3.3.2 spammy=arrangements, Steven, enemy, Munroe X-HELO: mx0a-001b2d01.pphosted.com Subject: Re: [PATCH 3/8] float128: Add wrappers for IEEE functions. From: Steven Munroe Reply-To: munroesj@linux.vnet.ibm.com To: Joseph Myers Cc: "Gabriel F. T. Gomes" , libc-alpha@sourceware.org In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Date: Tue, 06 Dec 2016 02:39:00 -0000 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16120602-8235-0000-0000-00000A1FDECC X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006201; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000194; SDB=6.00789841; UDB=6.00382434; IPR=6.00567581; BA=6.00004942; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013551; XFM=3.00000011; UTC=2016-12-06 02:39:18 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16120602-8236-0000-0000-0000376A755B Message-Id: <1480991949.13834.26.camel@oc7878010663> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-06_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1612060039 X-SW-Source: 2016-12/txt/msg00123.txt.bz2 On Tue, 2016-12-06 at 00:30 +0000, Joseph Myers wrote: > 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. > I am not disagreeing with the goal, but I am questioning the priorities. > 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. > Good then we will only do the minimum to complete the current patch set. As you suggest. > 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). > That is exactly what I am worried about. Perfection is the enemy of good.