From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id 9F8F2383E80D for ; Thu, 21 May 2020 15:58:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9F8F2383E80D Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-105-_Gm2YOvDPm6vUPSLUO_8cw-1; Thu, 21 May 2020 11:58:50 -0400 X-MC-Unique: _Gm2YOvDPm6vUPSLUO_8cw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9F99B18B6424; Thu, 21 May 2020 15:58:49 +0000 (UTC) Received: from localhost (unknown [10.33.36.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4F60670461; Thu, 21 May 2020 15:58:49 +0000 (UTC) Date: Thu, 21 May 2020 16:58:48 +0100 From: Jonathan Wakely To: libstdc++@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Let numeric_limits::is_iec559 reflect -ffast-math Message-ID: <20200521155848.GF2678@redhat.com> References: <2471679.QqfNXX16uU@excalibur> <20200521142449.GE2678@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable 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:58:53 -0000 On 21/05/20 17:46 +0200, Marc Glisse wrote: >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... Good point about ODR violations. Maybe we should just let numeric_limits fade away and be irrelevant, and replace it with something better which can be more useful.