From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3060 invoked by alias); 19 Aug 2018 19:47:22 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 3040 invoked by uid 89); 19 Aug 2018 19:47:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: cc-smtpout1.netcologne.de Received: from cc-smtpout1.netcologne.de (HELO cc-smtpout1.netcologne.de) (89.1.8.211) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 19 Aug 2018 19:47:19 +0000 Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id 4A513135C1; Sun, 19 Aug 2018 21:47:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1534708037; bh=aReltrVWP7bL0ICzcXGpM8qEYtze7kcashdHhHG3+SY=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To:From; b=ZK+7s8I4PgPuSpvebOx098O/jFtyMZyVCrEdpwZCLDLyNUdm4lbLsVuWSHJgXA5KF cnbQvtZeVUz+c4V67UrBMRtHFbYbQ0kuVzXKUhuYj2AyUJkiTvdc8hBzXrtWjSrpMu LPlASgf0ptTFV1Bh4mh1JeyJNSl95Dj+3vJ1mtahiqED0t/b9F/ZTwryEw57MH6v3h EKy/c5jKANpLiXWPCuXP8WmLhMr1y44MuF/8YEzn6LjwYrJUj04I8qMwgoyU9USqEv WWdr+CImZ0HzV8xo2A5ywPn1X8D7uBkUQOTtIiK9khmyffhKd2LDzWu5whxTqt9z/F q2RLfyrV2hgEg== Received: from localhost (localhost [127.0.0.1]) by cc-smtpin2.netcologne.de (Postfix) with ESMTP id 4759B11E8D; Sun, 19 Aug 2018 21:47:17 +0200 (CEST) Received: from [78.35.157.112] (helo=cc-smtpin2.netcologne.de) by localhost with ESMTP (eXpurgate 4.6.0) (envelope-from ) id 5b79c945-01b0-7f0000012729-7f000001e302-1 for ; Sun, 19 Aug 2018 21:47:17 +0200 Received: from [192.168.178.68] (xdsl-78-35-157-112.netcologne.de [78.35.157.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cc-smtpin2.netcologne.de (Postfix) with ESMTPSA; Sun, 19 Aug 2018 21:47:14 +0200 (CEST) Subject: Re: [PATCH] Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN intrinsics To: Janne Blomqvist , Fortran List , GCC Patches References: <20180810204728.20191-1-blomqvist.janne@gmail.com> From: Thomas Koenig Message-ID: Date: Sun, 19 Aug 2018 19:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2018-08/txt/msg00074.txt.bz2 Hi Janne, > On Fri, Aug 10, 2018 at 11:47 PM, Janne Blomqvist > wrote: > >> For floating point types, the question is what MAX(a, NaN) or MIN(a, >> NaN) should return (where "a" is a normal number). There are valid >> usecases for returning either one, but the Fortran standard doesn't >> specify which one should be chosen. Also, there is no consensus among >> other tested compilers. In short, it's a mess. So lets just do >> whatever is fastest, which is using MAX_EXPR/MIN_EXPR which are not >> defined to do anything in particular if one of the operands is a NaN. >> >> Regtested on x86_64-pc-linux-gnu, Ok for trunk? OK. Could you also document this behavior in the "Compiler Characteristics" section, and make mention of the change in gcc-9/changes.html ? Regards Thomas