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 [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 2777E388B01D for ; Fri, 22 May 2020 16:39:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2777E388B01D 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-182-uxXZ1v3gM-igrjkdQeNuQw-1; Fri, 22 May 2020 12:39:51 -0400 X-MC-Unique: uxXZ1v3gM-igrjkdQeNuQw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4C175100945B; Fri, 22 May 2020 16:39:44 +0000 (UTC) Received: from localhost (unknown [10.33.36.13]) by smtp.corp.redhat.com (Postfix) with ESMTP id DE88D5C1D0; Fri, 22 May 2020 16:39:43 +0000 (UTC) Date: Fri, 22 May 2020 17:39:42 +0100 From: Jonathan Wakely To: Matthias Kretz Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Let numeric_limits::is_iec559 reflect -ffast-math Message-ID: <20200522163942.GO2678@redhat.com> References: <2471679.QqfNXX16uU@excalibur> <20200521142449.GE2678@redhat.com> <4545252.oCjhQSYjh5@excalibur> MIME-Version: 1.0 In-Reply-To: <4545252.oCjhQSYjh5@excalibur> X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 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_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 22 May 2020 16:39:54 -0000 On 22/05/20 09:49 +0200, Matthias Kretz wrote: >On Donnerstag, 21. Mai 2020 17:46:01 CEST 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. > >But these ODR violations happen in any case: The floating-point types are >different types with or without -ffast-math (and related) flags. They behave >differently. Compiling a function in multiple TUs with different flags >produces observably different results. Choosing a single one of them is >obviously fragile and broken. That's the spirit of an ODR violation... > >It would sometimes be useful to have different types: >float, float_no_nan, float_no_nan_no_signed_zero, ... Sure. There are ODR violations like that, and then there are ones like: template struct X { conditional_t::is_iec559, T, BigNum> val; }; I'm generally not concerned about ODR violations where one TU behaves as requested by the flags used to compile that TU and another behaves as requested by the flats used to compile that second TU. That happens all the time with -fno-exceptions and -fno-rtti and such like. That causes ODR violations too, but of the kind where each definition does what was requested. Constants defined by the library changing value is a bit more concerning. But I don't know if it's really a problem in this case.