public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "sliwa at cft dot edu dot pl" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/15852] issues related to floating point precision
Date: Tue, 08 Jun 2004 18:51:00 -0000	[thread overview]
Message-ID: <20040608185135.16697.qmail@sourceware.org> (raw)
In-Reply-To: <20040606180702.15852.sliwa@theta1.cft.edu.pl>


------- Additional Comments From sliwa at cft dot edu dot pl  2004-06-08 18:51 -------
Subject: Re:  issues related to floating point precision


On Sun, Jun 06, 2004 at 07:35:12PM -0000, jsm at polyomino dot org dot uk wrote:
> 
> ------- Additional Comments From jsm at polyomino dot org dot uk  2004-06-06 19:35 -------
> Subject: Re:  issues related to floating point precision
> 
> On Sun, 6 Jun 2004, pinskia at gcc dot gnu dot org wrote:
> 
> > Not a bug, read the references in bug 323.
> 
> You mean "known bug", not "not a bug".  Excess precision is allowed by
> C99, and you can even define FLT_EVAL_METHOD to -1 to say that it's

What about fortran and the comparison issues? It seems that the Intel
compiler takes care of them. Consider this example:

//assume that
float x=0.4, y=0.1; // I mean float values!
//then let
float z=x+y;
//then this is true with -ffloat-store,
// bacause z is chopped to 0.5, whereas x+y not:
if(x+y > z)
  printf("not good...\n");


This issue is the reason for a failure with BLAS test.

BTW, being within the standards does not mean being useful.

Regards,
C.S.


> indeterminate when there's excess precision (which at present it is, given
> that spills reduce excess precision unpredictably), but we define
> FLT_EVAL_METHOD to 2 on x86 (saying that expressions are predictably
> evaluated as long double), and even with -ffloat-store we don't follow the
> standard rules that conversions to the same or narrower type (by
> assignment, cast and (probably) function call and return) get rid of
> excess precision (but note that conversions of float to double don't get
> rid of excess precision even if the float is being stored with the
> precision of long double).  That we don't get rid of excess precision on
> casts is clearly a bug, as is the bad definition of FLT_EVAL_METHOD.
> 
> 
> 
> -- 
> 
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15852
> 
> ------- You are receiving this mail because: -------
> You reported the bug, or are watching the reporter.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15852


      parent reply	other threads:[~2004-06-08 18:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-06 18:07 [Bug target/15852] New: " sliwa at theta1 dot cft dot edu dot pl
2004-06-06 18:13 ` [Bug target/15852] " pinskia at gcc dot gnu dot org
2004-06-06 19:35 ` jsm at polyomino dot org dot uk
2004-06-08 18:51 ` sliwa at cft dot edu dot pl [this message]

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=20040608185135.16697.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).