From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106616 invoked by alias); 5 Dec 2016 22:52:02 -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 106597 invoked by uid 89); 5 Dec 2016 22:52:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,RCVD_IN_SEMBACKSCATTER,URIBL_RED autolearn=no version=3.3.2 spammy=associates, Hx-languages-length:2283, emerging 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> Content-Type: text/plain; charset="UTF-8" Date: Mon, 05 Dec 2016 22:52:00 -0000 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16120522-0024-0000-0000-000015317D51 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006200; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000194; SDB=6.00789765; UDB=6.00382388; IPR=6.00567505; 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.00013550; XFM=3.00000011; UTC=2016-12-05 22:51:48 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16120522-0025-0000-0000-000046B55826 Message-Id: <1480978305.13834.14.camel@oc7878010663> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-12-05_16:,, 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-1612050337 X-SW-Source: 2016-12/txt/msg00120.txt.bz2 On Mon, 2016-12-05 at 18:50 +0000, Joseph Myers wrote: > On Mon, 5 Dec 2016, Gabriel F. T. Gomes wrote: > > > On Wed, 9 Nov 2016 21:38:07 +0000 > > Joseph Myers wrote: > > > > > On Wed, 9 Nov 2016, Gabriel F. T. Gomes wrote: > > > > > > > From: "Paul E. Murphy" > > > > > > > > These are copied from the long double version. posix style > > > > errors are assumed, and inlined. Where a function is not > > > > defined by TS 18661-3, the wrapper is not implemented. > > > > > > I don't think float128-specific wrappers like this are appropriate. All > > > these wrappers should be type-generic. If you put type-generic wrappers > > > as math/w_*_template.c, will the existing wrappers with matherr support > > > still take precedence for existing types? > > > > They won't. > > > > The files generated for the functions listed in gen-libm-calls > > (in /math/) are always generated, regardless of the existence > > of the same file in the source dir. And the generated-files take > > precedence over the files in the source dir. > > > > Do you have any suggestions on how to proceed? > > Source files in sysdeps certainly take precedence; that's by design, so > that architectures can easily have their own implementations that override > the templates. Are you saying that this only works for source files in > sysdeps and not for those in math/? > > If so, then the existing log1p and scalbln wrappers should just be made > into type-generic templates like I did with ilogb; there is nothing in > those wrappers using the _LIB_VERSION / matherr / __kernel_standard > functionality that we want to obsolete and so don't want to form part of > the interface to new functions. For the rest of the existing wrappers, > this indicates more of the steps towards deprecation are needed as part of > adding the new wrappers. > Are these changes really necessary at this time? I appropriate your desire to get a jump on the emerging standards but the associates changes are a constant churn on the code base and impacts our work. Deferring the C17 work (and associated restructuring) until 2.26 will expedite enabling our base _Float128 support in time for 2.25.