From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44351 invoked by alias); 19 Sep 2017 15:12:32 -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 44339 invoked by uid 89); 19 Sep 2017 15:12:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE,T_COMPENSATION autolearn=no version=3.3.2 spammy=H*r:172.16.2, H*F:D*br, D*br X-HELO: mo20.mail-out.ovh.net Date: Tue, 19 Sep 2017 15:12:00 -0000 From: "Gabriel F. T. Gomes" To: Tulio Magno Quites Machado Filho CC: Subject: Re: [PATCH v3 2/5] powerpc: Add redirection for finitef128, isinf128, and isnanf128 Message-ID: <20170919121220.1229d368@keller.br.ibm.com> In-Reply-To: <87efr2izs5.fsf@linux.vnet.ibm.com> References: <20170912123435.6592-1-gabriel@inconstante.eti.br> <20170912123435.6592-3-gabriel@inconstante.eti.br> <87efr2izs5.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-ClientProxiedBy: EX2.emp.local (172.16.2.2) To EX1.emp.local (172.16.2.1) X-Ovh-Tracer-Id: 3736580317034958504 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelledrheejgdekkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-SW-Source: 2017-09/txt/msg00739.txt.bz2 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. 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. >> +/* 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?