From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-481802-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 14363 invoked by alias); 18 Jul 2018 13:26:19 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 14324 invoked by uid 89); 18 Jul 2018 13:26:18 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=infinity, 18.07.2018, 18072018, our
X-HELO: mo4-p00-ob.smtp.rzone.de
Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de) (85.215.255.25) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 18 Jul 2018 13:26:16 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1531920374;	s=strato-dkim-0002; d=tkoenig.net;	h=To:References:Message-Id:Cc:Date:In-Reply-To:From:Subject:	X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender;	bh=ClO5s5YVuQPWH5ovz5/z6wAbFyFk+Y7DOWaqqDQeBAo=;	b=OGSpV1H6lgfabepujfioHAvOJ9fCo0goYZgtpVuSMjg5O5GWM9KOBK99ZOBSygERnf	viqDl+2ghkexd/2xY2vxj++rE2AMHa5OIDsfpQEoEayHTebxF39Y/0V0qr4ZWpjtYusU	/ioJ6zKg05zaqQh0aTYg5OCsENZUL0F9JQDmTmXPkpL+oY4vA66DZkmAz093jvB1SNAi	VEBebQJox/2LGnf7r7kjuYJFQE8oxb9IQMIU2bqpPbtdm4HZjuTIZUbvH8j0Cs08Egdh	yGvifAp8sQLbM/SB6RdjJ/HC24AsbRb7FviY8iHY9d6WDU4BjoObhi0yCd7cxuovyAnK	L0XA==
Content-Type: text/plain;	charset=us-ascii
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH][Fortran][v2] Use MIN/MAX_EXPR for min/max intrinsics
From: =?utf-8?Q?Thomas_K=C3=B6nig?= <tk@tkoenig.net>
In-Reply-To: <5B4F21E0.3060307@foss.arm.com>
Date: Wed, 18 Jul 2018 13:26:00 -0000
Cc: Janne Blomqvist <blomqvist.janne@gmail.com>, Thomas Koenig <tkoenig@netcologne.de>, Richard Biener <richard.guenther@gmail.com>, "fortran@gcc.gnu.org" <fortran@gcc.gnu.org>, GCC Patches <gcc-patches@gcc.gnu.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2AD7441E-7E57-47EC-9073-92375938B8B8@tkoenig.net>
References: <5B4DE283.9060100@foss.arm.com> <CAFiYyc2F_H1bSCQg+caLQr8WnqExtkAVyAhaQMky_HbZCC=5hQ@mail.gmail.com> <5B4DF325.2050609@foss.arm.com> <9d0cf3dc-8c5c-bbb2-960c-386b2c936a50@netcologne.de> <CAO9iq9GYUswbCaU0_WOZ5tppNY7RU7mF26gEqA19F8aWMJtqvw@mail.gmail.com> <CAO9iq9HGgS5rXuHOVqY6F_uBGE8uakiLd5SMQEK3eenCC=EaTA@mail.gmail.com> <5B4F21E0.3060307@foss.arm.com>
To: Kyrill Tkachov <kyrylo.tkachov@foss.arm.com>
X-SW-Source: 2018-07/txt/msg00999.txt.bz2

Hi Kyrlll,

> Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov <kyrylo.tkachov@foss.arm.co=
m>:
>=20
> Thomas, Janne, would this relaxation of NaN handling be acceptable given =
the benefits
> mentioned above? If so, what would be the recommended adjustment to the n=
an_1.f90 test?

I would be a bit careful about changing behavior in such a major way. What =
would the results with NaN and infinity then be, with or without optimizati=
on? Would the results be consistent with min(nan,num) vs min(num,nan)? Woul=
d they be consistent with the new IEEE standard?

In general, I think that min(nan,num) should be nan and that our current be=
havior is not the best.

Does anybody have dats points on how this is handled by other compilers?

Oh, and if anything is changed, then compile and runtime behavior should al=
ways be the same.

Regards, Thomas