From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115740 invoked by alias); 17 Jul 2018 15:37:09 -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 115652 invoked by uid 89); 17 Jul 2018 15:37:08 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:5hQ@mai, H*f:sk:caLQr8W, H*f:sk:5B4DF32, H*i:sk:5B4DF32 X-HELO: cc-smtpout2.netcologne.de Received: from cc-smtpout2.netcologne.de (HELO cc-smtpout2.netcologne.de) (89.1.8.212) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jul 2018 15:37:06 +0000 Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout2.netcologne.de (Postfix) with ESMTP id C384112898; Tue, 17 Jul 2018 17:37:03 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1531841823; bh=iF1CiaiCPmooHlrKP2XV+nYuH+pdByPhV91v141QjzM=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To:From; b=ECQ+3MkifNPsOW4pwKe6LgOtcd+ttKluduMe9G5qW0ROaRxFR88fJrMHcrcNq+1k7 yOfqBrC4nbeOah5IepgKQwJ8kPJTEfWMdaExpwuUAtxFhTzzsSXZ43lD/fFeZWASQL boHh0yL1fGA4c0wAqCdG8CIfq2s9LMa7MfiIdOYUgPoGPZ/2zQwBBdjvCMdrQ7Wmbk R1QXwzRQwJoiMLGYvKoavufPeYeZPOZaWzm2aoCQXByEjB4XQGbsv0a0ML+DcLFLsf fY+CbwURSto14mhuJzTl1GX13v9FUdbxnTiMt6Ate9GN5AObjkQSedSKhgRPIyVEoy SQw8JEC93xjbQ== Received: from localhost (localhost [127.0.0.1]) by cc-smtpin2.netcologne.de (Postfix) with ESMTP id BEE1C11EC3; Tue, 17 Jul 2018 17:37:03 +0200 (CEST) Received: from [78.35.156.152] (helo=cc-smtpin2.netcologne.de) by localhost with ESMTP (eXpurgate 4.6.0) (envelope-from ) id 5b4e0d1f-01b0-7f0000012729-7f0000019eba-1 for ; Tue, 17 Jul 2018 17:37:03 +0200 Received: from [192.168.178.68] (xdsl-78-35-156-152.netcologne.de [78.35.156.152]) (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; Tue, 17 Jul 2018 17:37:00 +0200 (CEST) Subject: Re: [PATCH][Fortran] Use MIN/MAX_EXPR for intrinsics or __builtin_fmin/max when appropriate To: Kyrill Tkachov , Richard Biener Cc: "fortran@gcc.gnu.org" , GCC Patches References: <5B4DE283.9060100@foss.arm.com> <5B4DF325.2050609@foss.arm.com> From: Thomas Koenig Message-ID: <9d0cf3dc-8c5c-bbb2-960c-386b2c936a50@netcologne.de> Date: Tue, 17 Jul 2018 15:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <5B4DF325.2050609@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2018-07/txt/msg00939.txt.bz2 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. 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. So, the Fortran standard does not impose many requirements. I do think that a patch such as yours should not change the current behavior unless we know what it does and do think it is a good idea. Hmm... Having said that, I think we pretty much cover all the corner cases in nan_1.f90, so if that test passes without regression, then that aspect should be fine. Question: You have found an advantage on Aarm64. Do you have access to other architectures so see if there is also a speed advantage, or maybe a disadvantage? Regards Thomas