From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80932 invoked by alias); 17 Jul 2018 20:35:47 -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 80911 invoked by uid 89); 17 Jul 2018 20:35:46 -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=UD:changes.html, changes.html, H*f:sk:CAO9iq9, changeshtml X-HELO: mail-yb0-f180.google.com Received: from mail-yb0-f180.google.com (HELO mail-yb0-f180.google.com) (209.85.213.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jul 2018 20:35:45 +0000 Received: by mail-yb0-f180.google.com with SMTP id l16-v6so956512ybk.11; Tue, 17 Jul 2018 13:35:44 -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=BGNntOhwxp5UWi0zn5rXe64C1dXmxh0hcaSTqPSj3kc=; b=BClu2RMeYgljfbipFeENnPLcdZHXljKgqDwrnmSxm4SXnnh8nuog8gzYoL+okvJ5vU I/pWbwAnrA6lkPEoP5wF10yEjkW5iI0N276JK5NKEjWUUvVXaySa/bkkgc4EdSNsnc9O N1P5Cz9tV6XFsYAL6sEy9v2fd1NpAZ9jSfS1KpaKnP4hqEZsfQsh0ulpdYdsajhtbH+R Cn7SxWBPlmX/9pTk2sgN1OupFw6g/FyDwKJ0goWhgrQP9eQQmYfBY+3yiMd1svoU8LP0 ScZq8JleZHEB1Y1xBbJlU08B+a4oES0Ojs0OpqC+gpMbY1Bjn+5MqgnzNcutx0McAsIl LzlQ== MIME-Version: 1.0 Received: by 2002:a0d:e304:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 13:35:42 -0700 (PDT) In-Reply-To: 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:35: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/msg00964.txt.bz2 On Tue, Jul 17, 2018 at 11:06 PM, Janne Blomqvist wrote: > 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 > Oh, and on http://754r.ucbtest.org/ there is information about the next update after IEEE 754-2008. In particular, http://754r.ucbtest.org/changes.html notes that the above mentioned {max,min}num{,_mag} have been deleted, and "new {min,max}imum{,Number,Magnitude,MagnitudeNumber} operations are recommended; NaN and signed zero handling are changed from 754-2008 5.3.1. ". -- Janne Blomqvist