From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sourceware.org (Postfix) with ESMTPS id 711603972432; Thu, 21 May 2020 15:46:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 711603972432 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=inria.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=marc.glisse@inria.fr X-IronPort-AV: E=Sophos;i="5.73,418,1583190000"; d="scan'208";a="349305132" Received: from 225.95.12.109.rev.sfr.net (HELO stedding) ([109.12.95.225]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 May 2020 17:46:02 +0200 Date: Thu, 21 May 2020 17:46:01 +0200 (CEST) From: Marc Glisse X-X-Sender: glisse@stedding.saclay.inria.fr Reply-To: libstdc++@gcc.gnu.org To: Jonathan Wakely cc: Matthias Kretz , gcc-patches@gcc.gnu.org, libstdc++ Subject: Re: [PATCH] Let numeric_limits::is_iec559 reflect -ffast-math In-Reply-To: <20200521142449.GE2678@redhat.com> Message-ID: References: <2471679.QqfNXX16uU@excalibur> <20200521142449.GE2678@redhat.com> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 15:46:07 -0000 On Thu, 21 May 2020, Jonathan Wakely wrote: > On 27/04/20 17:09 +0200, Matthias Kretz wrote: >> >> From: Matthias Kretz >> >> PR libstdc++/84949 >> * include/std/limits: Let is_iec559 reflect whether >> __GCC_IEC_559 says float and double support IEEE 754-2008. >> * testsuite/18_support/numeric_limits/is_iec559.cc: Test IEC559 >> mandated behavior if is_iec559 is true. >> * testsuite/18_support/numeric_limits/infinity.cc: Only test inf >> behavior if is_iec559 is true, otherwise there is no guarantee >> how arithmetic on inf behaves. >> * testsuite/18_support/numeric_limits/quiet_NaN.cc: ditto for >> NaN. >> * testsuite/18_support/numeric_limits/denorm_min-1.cc: Compile >> with -ffast-math. >> * testsuite/18_support/numeric_limits/epsilon-1.cc: ditto. >> * testsuite/18_support/numeric_limits/infinity-1.cc: ditto. >> * testsuite/18_support/numeric_limits/is_iec559-1.cc: ditto. >> * testsuite/18_support/numeric_limits/quiet_NaN-1.cc: ditto. > > I'm inclined to go ahead and commit this (to master only, obviously). > It certainly seems more correct to me, and we'll probably never find > out if it's "safe" to do unless we actually change it and see what > happens. > > Marc, do you have an opinion? I don't have a strong opinion on this. I thought we were refraining from changing numeric_limits based on flags (like -fwrapv for modulo) because that would lead to ODR violations when people link objects compiled with different flags. There is a value in libstdc++.so, which may have been compiled with different flags than the application. Also, IIRC part of the effect of -ffast-math is at link time (linking some object that enables flush-to-zero). Anyway, as discussed in the PR, what numeric_limits says here is not very meaningful, and users can't rely on it 100%. By default, numeric_limits gives yes if IEC support exists on the platform. The change would sometimes make it say no, when we know for sure that this support is not enabled at the beginning of the translation unit. Why not... -- Marc Glisse