public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <jh@suse.cz>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: Andreas Schwab <schwab@suse.de>, Jan Hubicka <jh@suse.cz>,
	gcc-patches@gcc.gnu.org
Subject: Re: Converting floor to rint
Date: Thu, 07 Nov 2002 07:01:00 -0000	[thread overview]
Message-ID: <20021107150055.GC11315@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <m3y985tq4g.fsf@soliton.integrable-solutions.net>

> Andreas Schwab <schwab@suse.de> writes:
> 
> | Gabriel Dos Reis <gdr@integrable-solutions.net> 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 <fenv.h>) 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

  reply	other threads:[~2002-11-07 15:01 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-05  9:14 Simplify floating point conversions Jan Hubicka
2002-11-05  9:38 ` Richard Henderson
2002-11-05  9:42   ` Jan Hubicka
2002-11-06  1:23   ` Simplify floating point conversions II Jan Hubicka
2002-11-06  3:08     ` Michael Matz
2002-11-06  4:36       ` Jan Hubicka
2002-11-06  9:54     ` Jan Hubicka
2002-11-06 10:09       ` Richard Henderson
2002-11-06 13:11         ` Jan Hubicka
2002-11-06 13:19           ` Jan Hubicka
2002-11-06 13:35           ` Gabriel Dos Reis
2002-11-06 13:36             ` Jan Hubicka
2002-11-06 14:06               ` Gabriel Dos Reis
2002-11-06 14:29             ` Converting floor to rint Jan Hubicka
2002-11-06 14:47               ` Richard Henderson
2002-11-06 14:53                 ` Jan Hubicka
2002-11-06 14:55               ` Gabriel Dos Reis
2002-11-07  1:21                 ` Jan Hubicka
2002-11-07  1:32                   ` Jakub Jelinek
2002-11-07  1:33                   ` Gabriel Dos Reis
2002-11-07  1:44                     ` Jan Hubicka
2002-11-07  1:52                       ` Jakub Jelinek
2002-11-07  1:54                         ` Jan Hubicka
2002-11-07  2:04                     ` Jan Hubicka
2002-11-07  4:47                       ` Gabriel Dos Reis
2002-11-07  4:56                         ` Jan Hubicka
2002-11-07  5:14                           ` Andreas Schwab
2002-11-07  5:27                             ` Gabriel Dos Reis
2002-11-07  5:31                               ` Jan Hubicka
2002-11-07  5:35                                 ` Andreas Schwab
2002-11-07  5:22                           ` Gabriel Dos Reis
2002-11-07  5:43                             ` Andreas Schwab
2002-11-07  6:23                               ` Gabriel Dos Reis
2002-11-07  7:01                                 ` Jan Hubicka [this message]
2002-11-07  7:18                                   ` Gabriel Dos Reis
2002-11-06 13:48         ` Simplify floating point conversions III Jan Hubicka
2002-11-06 14:55           ` Richard Henderson
2002-11-07  2:54             ` Simplify floating point conversions IV Jan Hubicka
2002-11-18 15:01               ` Richard Henderson
2002-11-05 11:14 ` Simplify floating point conversions Geoff Keating
2002-11-06  1:09   ` Jan Hubicka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021107150055.GC11315@atrey.karlin.mff.cuni.cz \
    --to=jh@suse.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=gdr@integrable-solutions.net \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).