From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 82012 invoked by alias); 17 Jul 2018 20:06:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 81981 invoked by uid 89); 17 Jul 2018 20:06:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:9d0cf3d, H*c:alternative X-HELO: mail-yb0-f170.google.com Received: from mail-yb0-f170.google.com (HELO mail-yb0-f170.google.com) (209.85.213.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jul 2018 20:06:22 +0000 Received: by mail-yb0-f170.google.com with SMTP id x15-v6so926845ybm.2; Tue, 17 Jul 2018 13:06:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8u1PpTFe2x1vgRkUIP2wnEc6/nXxlwRqy/zL8Tq27U4=; b=Y26YJOyhIl/Ezj4Okvdmcu6xnqXdfyYALenth+e+SQ0CdRNwsMPtFrSxY5tQBzfVVf Y9CYhPgHTXEAsHkCHLSqpFt9jZBuLFQ7U65tIUhtjzS5rtwR928phDmPE1DQHkPMIELV N1qPLwvumsA9hUOlfptwfEQ3Iby0cLwKdV40fndGP4zgwUej4dQNGeA/6gH/jXREpgVl aaUVujiE1cqv28OOssaTZwc0CFF+g8XX/K4p6xzFVd++vpn678DdlfsS4AGrecePWPRx SQvytW3q7d+uaaOcahLidy77cU3BwA/khOe4IpYU6y0vNxodiqXv+NOqUYvbgOhSy44M zq9Q== MIME-Version: 1.0 Received: by 2002:a0d:e304:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 13:06:19 -0700 (PDT) In-Reply-To: <9d0cf3dc-8c5c-bbb2-960c-386b2c936a50@netcologne.de> References: <5B4DE283.9060100@foss.arm.com> <5B4DF325.2050609@foss.arm.com> <9d0cf3dc-8c5c-bbb2-960c-386b2c936a50@netcologne.de> From: Janne Blomqvist Date: Tue, 17 Jul 2018 20:06:00 -0000 Message-ID: Subject: Re: [PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate To: Thomas Koenig Cc: Kyrill Tkachov , Richard Biener , "fortran@gcc.gnu.org" , GCC Patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-07/txt/msg00960.txt.bz2 On Tue, Jul 17, 2018 at 6:36 PM, Thomas Koenig wrote: > Hi Kyrill, > > The current implementation expands to: >> mvar = a1; >> if (a2 .op. mvar || isnan (mvar)) >> mvar = a2; >> if (a3 .op. mvar || isnan (mvar)) >> mvar = a3; >> ... >> return mvar; >> >> That is, if one of the operands is a NaN it will return the other >> argument. >> If both (all) are NaNs, it will return NaN. This is the same as the >> semantics of fmin/max >> as far as I can tell. >> > > I've looked at the F2008 standard, and, interestingly enough, the > requirement on MIN and MAX do not mention NaNs at all. 13.7.106 > has, for MAX, > > Result Value. The value of the result is that of the largest argument. > > plus some stuff about character variables (not relevant here). Similar > for MIN. > FWIW, this has not changed in the latest(?) draft for F2018 (N2146), see 16.9.125. Also, the section on IEEE_ARITHMETIC (14.9) does not mention > comparisons; also, "Complete conformance with IEC 60559:1989 is not > required", what is required is the correct support for +,-, and *, > plus support for / if IEEE_SUPPORT_DIVIDE is covered. > Interestingly, here the F2018 draft has new intrinsics in the IEEE_ARITHMETIC module, IEEE_MAX_NUM, IEEE_MAX_NUM_MAG, IEEE_MIN_NUM, IEEE_MIN_NUM_MAG. These correspond to the {max,min}num{,_mag} operations in IEEE 754-2008, which AFAICT has the same NaN semantics as __builtin_fmax etc. > So, the Fortran standard does not impose many requirements. If so, why don't we just use {MAX,MIN}_EXPR unconditionally? Those who worry about the behavior wrt. NaNs, infinities etc. can use the intrinsics from IEEE_ARITHMETIC? This thread also has some interesting discussion on the topic: https://github.com/JuliaLang/julia/issues/7866 -- Janne Blomqvist