From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106560 invoked by alias); 13 Jun 2018 21:36:07 -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 106548 invoked by uid 89); 13 Jun 2018 21:36:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com From: Tulio Magno Quites Machado Filho To: Joseph Myers Cc: libc-alpha@sourceware.org, gabriel@inconstante.eti.br, raji@linux.ibm.com Cc: Subject: Re: [PATCH 7/9] Refactor math-finite.h and introduce mathcalls-redir.h In-Reply-To: References: <20180606223909.16675-1-tuliom@linux.ibm.com> <20180606223909.16675-8-tuliom@linux.ibm.com> User-Agent: Notmuch/0.25 (http://notmuchmail.org) Emacs/25.3.1 (x86_64-redhat-linux-gnu) Date: Wed, 13 Jun 2018 21:36:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 18061321-0036-0000-0000-000009FCC5FF X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00009185; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000265; SDB=6.01046533; UDB=6.00535986; IPR=6.00825509; MB=3.00021630; MTD=3.00000008; XFM=3.00000015; UTC=2018-06-13 21:36:02 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18061321-0037-0000-0000-000047BAA25E Message-Id: <878t7icqtd.fsf@linux.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-13_09:,, signatures=0 X-SW-Source: 2018-06/txt/msg00366.txt.bz2 Joseph Myers writes: > On Wed, 6 Jun 2018, Tulio Magno Quites Machado Filho wrote: > >> On a new enough compiler, redirecting the same function twice can cause >> -Werror=pragmas errors. This issue may appear when redirecting an ISO C >> floating point function to a different ABI at the same time that finite >> redirections are expected. > > Does this issue already appear with -mlong-double-64? If so, it should > definitely be separated out from this patch series and have a bug filed in > Bugzilla as usual for anything fixing a bug that was user-visible in a > release. Yes, I can reproduce it in our tests if I replace -mlong-double-128 with -mlong-double-64. However, this is not user-visible because this warning is ignored in system headers. Do you still think a bug report is necessary? > The approach taken in this patch involves a lot of duplication of both > function prototypes and the feature-test-macro conditions on when those > functions are declared (duplicating them for functions not included in > math-finite.h, when previously only those in math-finite.h had such > duplication). Such duplication is, from experience, fragile and a bad > idea; the conditions and declarations are too likely to get out of sync. Agreed. > Instead, I'd suggest merging bits/math-finite.h into bits/mathcalls.h as > much as possible - have macros such as __MATHCALL_FINITE that are called > in bits/mathcalls.h to declare the functions with __*_finite variants, and > with __MATHCALL_FINITE defined the same as __MATHCALL when the finite > function variants aren't in use. That way you have just a single > redirection for each function. (You'll need a sysdeps bits/ header for an > architecture, i.e. ia64, to declare it doesn't support the _finite > functions at all.) It doesn't work well this way because we have prototypes with extra attributes, e.g: __MATHDECL_1 (int, totalorder,, (_Mdouble_ __x, _Mdouble_ __y)) __attribute__ ((__const__)); So, if I do not define __MATHDECL_1 in bits/math-finite.h, this code would end up as an invalid code: __attribute__ ((__const__)); I managed to remove bits/math-redir.h and modified both math.h and bits/math-finite.h to reuse bits/mathcalls.h. I had to keep using __MATH_DECLARE_FINITE and __MATH_DECLARE_NON_FINITE. Would this be acceptable? -- Tulio Magno