From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15628 invoked by alias); 7 Nov 2002 15:01:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 15570 invoked from network); 7 Nov 2002 15:00:57 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 7 Nov 2002 15:00:57 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id E64A94F9A3; Thu, 7 Nov 2002 16:00:55 +0100 (CET) Date: Thu, 07 Nov 2002 07:01:00 -0000 From: Jan Hubicka To: Gabriel Dos Reis Cc: Andreas Schwab , Jan Hubicka , gcc-patches@gcc.gnu.org Subject: Re: Converting floor to rint Message-ID: <20021107150055.GC11315@atrey.karlin.mff.cuni.cz> References: <20021106222922.GH1316@atrey.karlin.mff.cuni.cz> <20021107092112.GF7964@kam.mff.cuni.cz> <20021107100359.GI7964@kam.mff.cuni.cz> <20021107125643.GA11315@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-SW-Source: 2002-11/txt/msg00458.txt.bz2 > Andreas Schwab writes: > > | Gabriel Dos Reis writes: > | > | |> "may" part refers to the fact whether the programmer might want > | |> to run rint() under a particular floating-point control mode that > | |> would permit rint() to raise the inexact exception. > | |> rint() cannot unconditionally set it. If FENV_ACCESS is on and > | |> FE_INEXACT is supported then rint() should raise the exception if > | |> appropriate. That is my understanding. > | > | If the implementation defines __STDC_IEC_559__ then F.9.6.4 applies. I > | have no copy of IEC 60559, but if it states that rint must raise the > | exception then it must do it independent of FENV_ACCESS. Yes, IEC seems to be clear about the trap: [#1] The rint functions differ from the nearbyint functions only in that they do raise the ``inexact'' floating-point exception if the result differs in value from the argument. I would love to be enlightened about when this feature is usefull :) I can't think of any use for it. Sadly most people use rint/lrint and not nearbyint/lrint that are more consistent. > > My concern is this: > > F.7.1 Environment management > > [#1] IEC 60559 requires that floating-point operations > implicitly raise floating-point exception status flags, and > that rounding control modes can be set explicitly to affect > result values of floating-point operations. When the state > for the FENV_ACCESS pragma (defined in ) is ``on'', > these changes to the floating-point state are treated as > *side effects* which respect sequence points.304) > > (my emphasis) So one can not consider rint as "attribute((const))" function and we can not do that in strict mode. > > | Otherwise, if > | __STDC_IEC_559__ is not defined, then no requirements on the exceptions > | are stated for rint, since 7.12.9.4 does not have a "shall". Can I detect somehow the cases when __STDC_IEC_559__ is not defined? This seems to be done by glibc in all cases, even with -ffast-math. Perhaps I can do the rint folding only with -ffast-math that would be enought for majority of 3D software that is about the only case where we get some oppurtunities for speedup from this transformations? Honza > > Agreed. > > -- Gaby