From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32387 invoked by alias); 10 Jul 2009 16:31:58 -0000 Received: (qmail 32342 invoked by uid 48); 10 Jul 2009 16:31:44 -0000 Date: Fri, 10 Jul 2009 16:31:00 -0000 Message-ID: <20090710163144.32341.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/40643] maxloc/minloc: Wrong result for NaN at position 1 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-07/txt/msg00890.txt.bz2 ------- 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