From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25686 invoked by alias); 28 May 2017 22:09:32 -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 25675 invoked by uid 89); 28 May 2017 22:09:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=H*r:rev.sfr.net, leaf X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 28 May 2017 22:09:30 +0000 Received: from 187.57.140.77.rev.sfr.net (HELO stedding) ([77.140.57.187]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 May 2017 00:09:31 +0200 Date: Sun, 28 May 2017 22:26:00 -0000 From: Marc Glisse To: Richard Biener cc: GCC Patches Subject: Re: builtin fenv functions In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2017-05/txt/msg02145.txt.bz2 On Fri, 26 May 2017, Richard Biener wrote: >>>> Similarly, I >>>> don't see div as a builtin in that file, only FILE* has special code, but >>>> that doesn't seem worth the trouble here. So I am only declaring the 5 >>>> "simple" functions, with minimal properties: leaf, nothrow, and for >>>> fegetround pure (glibc already declares it that way). We can then discuss >>>> the safety of future optimizations on a case by case basis. >>> >>> >>> +DEF_C99_BUILTIN (BUILT_IN_FERAISEEXCEPT, "feraiseexcept", >>> BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST) >>> >>> I think feraiseexcept shouldn't be nothrow? >> >> >> glibc marks it as nothrow. I can remove the nothrow flag for now, for >> safety. It may trap, but it does not throw a C++ exception AFAIU. > > Also with -fnon-call-exceptions? Hmm, maybe on windows where trap handlers turn into system exceptions which are handled like C++ exceptions... I am happy to remove nothrow. >>> But it may be pure. >> >> It writes to the exception register (aka memory for now), so I would hardly >> call it pure. > > But it doesn't have to be ordered with control word writes/reads, no? Not sure what you mean here. feraiseexcept(FE_DIVBYZERO) is equivalent to 1./0., it writes to the exception status flag. Its order with respect to fetestexcept must be preserved. >>> Likewise fetestexcept may be pure? >> >> >> Too unsafe for now, since any FP operation can write to the memory that >> fetestexcept reads. > > Ah... but then FP operations are not ordered with the builtins anyway, > only FP loads/stores would be. Since gcc doesn't handle fenv properly, people have been using a number of workarounds, in particular with pass-through asm, sometimes volatile, occasionally with the "memory" clobber. Some of those versions would still work with pure, but the attribute increases the likelyhood of breaking some of those uses, and I don't know if it would ever help in practice, so I would rather not add it for now. fegetround is very different since it can safely swap position with an adjacent float operation. > After all having builtins is only the first easiest step of properly modeling > dependences between FP ops and the FP control/exception registers. Yes, I didn't expect adding those 5 builtins (modulo the nothrow flag) to be controversial... -- Marc Glisse