From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29633 invoked by alias); 19 Aug 2015 15:31:51 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 29623 invoked by uid 89); 19 Aug 2015 15:31:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Aug 2015 15:31:49 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1ZS5To-0007mL-3h from joseph_myers@mentor.com ; Wed, 19 Aug 2015 08:40:44 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Wed, 19 Aug 2015 16:31:44 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1ZS5L4-00052S-Up; Wed, 19 Aug 2015 15:31:43 +0000 Date: Wed, 19 Aug 2015 15:32:00 -0000 From: Joseph Myers To: Richard Biener CC: David Sherwood , GCC Patches , Subject: Re: [PING][Patch] Add support for IEEE-conformant versions of scalar fmin* and fmax* In-Reply-To: Message-ID: References: <000001d0d5b0$5da4dbb0$18ee9310$@arm.com> <000001d0d8cf$2fb42770$8f1c7650$@arm.com> <000001d0d9a6$1efdc350$5cf949f0$@arm.com> <87fv3gbs36.fsf@e105548-lin.cambridge.arm.com> <8737zfbo2j.fsf@e105548-lin.cambridge.arm.com> <87y4h7a35q.fsf@e105548-lin.cambridge.arm.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2015-08/txt/msg01104.txt.bz2 On Wed, 19 Aug 2015, Richard Biener wrote: > As an additional point for many math functions we have to support errno > which means, like, BUILT_IN_SQRT can be rewritten to SQRT_EXPR > only if -fno-math-errno is in effect. But then code has to handle I'd say that for functions like that (which can be expanded inline only for -fno-math-errno) there should be no-errno built-in function variants that users can call even if -fmath-errno (if not expanded inline, they'd still result in a call to a libm function that might set errno). An example of a use for that is AArch64 sqrt intrinsics that need an architecture-specific built-in __builtin_aarch64_sqrtdf when __builtin_sqrt_noerrno would do just as well if it existed. As another example: various libm functions are marked in builtins.def as not setting errno, even though their proper semantics mean they might set errno; see bug 64101 for the example of erf. One such function is fma. But if you limit fma inline expansion (for calls to fma / __builtin_fma in the user's program; obviously this doesn't affect expansion via contraction of a * b + c) to allow for the possibility of errno setting, you definitely want a way for user programs to get back the efficient inline expansion if they don't need errno set; for example, glibc uses __builtin_fma in various cases if _FP_FAST_FMA, and does not need errno setting in those cases, so would want to use __builtin_fma_noerrno in the event of any such change. -- Joseph S. Myers joseph@codesourcery.com