public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/40643] maxloc/minloc: Wrong result for NaN at position 1
Date: Fri, 10 Jul 2009 16:31:00 -0000	[thread overview]
Message-ID: <20090710163144.32341.qmail@sourceware.org> (raw)
In-Reply-To: <bug-40643-13404@http.gcc.gnu.org/bugzilla/>



------- Comment #2 from jakub at gcc dot gnu dot org  2009-07-10 16:31 -------
Created an attachment (id=18174)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18174&action=view)
gcc45-pr40643.patch

Inline minmaxloc patch.
Is this the behavior we want?
If NaNs aren't supported and array size is known, no mask, then inline
maxloc/minloc should be quite a bit faster (condition should be just val <
limit
instead of val < limit || (pos == 0 && val == limit)).  On the other side, if
array size isn't known at compile time (or non-scalar mask is used) and NaNs
must be supported, the loop is more expensive.

I haven't touched minmaxval inline expansion yet, there I'm afraid for floating
point without -ffast-math the loop will have to be quite a bit slower than what
we do ATM, as we'd need to return -inf for maxval on array full of -infs (or
full of nans with at least one -inf), or nan for array full of nans, but for
empty array or completely masked away array -huge.

The patch also disables the inline expansion for -O0, I think at -O0 we should
aim at generating smaller and more easily debuggable code.  Probably we
shouldn't be expanding this inline for optimize_size either.


-- 


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


  parent reply	other threads:[~2009-07-10 16:31 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-03 18:15 [Bug fortran/40643] New: " burnus at gcc dot gnu dot org
2009-07-03 19:30 ` [Bug fortran/40643] " jakub at gcc dot gnu dot org
2009-07-05  9:12 ` fxcoudert at gcc dot gnu dot org
2009-07-10 16:31 ` jakub at gcc dot gnu dot org [this message]
2009-07-10 19:03 ` burnus at gcc dot gnu dot org
2009-07-14 13:26 ` jakub at gcc dot gnu dot org
2009-07-14 13:31 ` jakub at gcc dot gnu dot org
2009-07-14 19:18 ` tkoenig at gcc dot gnu dot org
2009-07-24  7:57 ` jakub at gcc dot gnu dot org
2009-12-05 21:54 ` tkoenig at gcc dot gnu dot org

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=20090710163144.32341.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).