From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70322 invoked by alias); 20 Sep 2017 13:46:18 -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 70309 invoked by uid 89); 20 Sep 2017 13:46:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,T_COMPENSATION autolearn=no version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com From: "Tulio Magno Quites Machado Filho" To: "Gabriel F. T. Gomes" Cc: libc-alpha@sourceware.org Cc: Subject: Re: [PATCH v3 2/5] powerpc: Add redirection for finitef128, isinf128, and isnanf128 In-Reply-To: <20170919121220.1229d368@keller.br.ibm.com> References: <20170912123435.6592-1-gabriel@inconstante.eti.br> <20170912123435.6592-3-gabriel@inconstante.eti.br> <87efr2izs5.fsf@linux.vnet.ibm.com> <20170919121220.1229d368@keller.br.ibm.com> User-Agent: Notmuch/0.25 (http://notmuchmail.org) Emacs/25.2.1 (x86_64-redhat-linux-gnu) Date: Wed, 20 Sep 2017 13:46:00 -0000 MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17092013-0016-0000-0000-0000078B4E33 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007768; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000230; SDB=6.00919769; UDB=6.00462112; IPR=6.00699996; BA=6.00005598; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017221; XFM=3.00000015; UTC=2017-09-20 13:46:13 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17092013-0017-0000-0000-00003B8BBD97 Message-Id: <877ewtiiu6.fsf@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-20_04:,, 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-1707230000 definitions=main-1709200187 X-SW-Source: 2017-09/txt/msg00782.txt.bz2 "Gabriel F. T. Gomes" writes: > On 19 Sep 2017, Tulio Magno Quites Machado Filho wrote: > >>"Gabriel F. T. Gomes" writes: >> >>> The errors are due to the unintended macro expansion of __finitef128 to >>> __redirect_finitef128 in math/bits/mathcalls-helper-functions.h. In >> >>AFAIU, the expansion of __finitef128 to __redirect_finitef128 in >>math/bits/mathcalls-helper-functions.h is expected. The problem happens when >>the same thing doesn't happen in include/math.h too. > > I mean unintended in the sense that the expansion of __finitef and > __finitel, which pertain to float and long double, are happening in > s_finite.c, which is the *double* implementation of finite. Compare that > with s_finitef.c, which only redefines __finitef, leaving the other macros > (__finite and __finitel) untouched. Got it! > On the other hand, I agree that my comments did not fully explain the > problem. They only mention the expansion in mathcalls-helper-functions.h > and do not say anything about the hidden prototypes in include/math.h. > > So, how about expanding this paragraph to: > > The errors are due to the unintended macro expansion of __finitef128 to > __redirect_finitef128 in math/bits/mathcalls-helper-functions.h. In > that header, __MATHDECL_1 takes '__finite' and 'f128' as arguments and > concatenates them. However, since '__finite' has been redefined in > s_finite.c, the function declaration becomes __redirect_finitef128: > > extern int __redirect___finitef128 (_Float128 __value) __attribute__ ((__nothrow__ )) __attribute__ ((__const__)); > > This declaration itself is OK. The problem arises when include/math.h > creates the hidden prototype ('hidden_proto (__finitef128)'), which > expands to: > > extern __typeof (__finitef128) __finitef128 __attribute__ ((visibility ("hidden"))); > > Since __finitef128 is not declared, __typeof fails. This effect was > already true for the 'float' and 'long double' versions and is now true > for float128. Likewise for isinsff128 and isnanf128. Looks good to me. >>> +/* The following definitions, although not related to the 'double' >>> + version of 'finite', are required to compensate for the unintended >>> + macro expansion of __finitef to __redirect___finitef, etc. in >>> + math/bits/mathcalls-helper-functions.h. */ >> >>Likewise. >>I suggest the following change: >> >>/* The following definitions, although not related to the 'double' >> version of 'finite', are required to guarantee the macro expansion >> of __finitef to __redirect___finitef, etc. in >> math/bits/mathcalls-helper-functions.h and include/math.h. */ > > The expansion in mathcalls-helper-functions.h is unintended, but we need > to guarantee the same expansion in include/math.h, so what about the > following: > > The following definitions, although not related to the 'double' version > of 'finite', are required to guarantee expansions (e.g.: from __finitef > to __redirect_finitef) in include/math.h, thus compensating for the > unintended macro expansions in math/bits/mathcalls-helper-functions.h. > > OK with these changes? Yes, assuming you also include the #undef lines I mentioned in my previous email. Thanks! -- Tulio Magno