From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30903 invoked by alias); 3 Nov 2011 15:56:53 -0000 Received: (qmail 30893 invoked by uid 22791); 3 Nov 2011 15:56:52 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-qy0-f182.google.com (HELO mail-qy0-f182.google.com) (209.85.216.182) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Nov 2011 15:56:38 +0000 Received: by qyk9 with SMTP id 9so742312qyk.20 for ; Thu, 03 Nov 2011 08:56:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.1.201 with SMTP id 9mr1271380qcg.252.1320335795721; Thu, 03 Nov 2011 08:56:35 -0700 (PDT) Received: by 10.229.251.195 with HTTP; Thu, 3 Nov 2011 08:56:35 -0700 (PDT) In-Reply-To: <20111103151153.GD3523@xvii.vinc17.org> References: <20111102090102.GA3523@xvii.vinc17.org> <4EB10F53.5010404@redhat.com> <20111103122956.GC3523@xvii.vinc17.org> <20111103151153.GD3523@xvii.vinc17.org> Date: Thu, 03 Nov 2011 15:56:00 -0000 Message-ID: Subject: Re: Compile-time floating-point expressions and subsequent detection of possible overflows etc -- during the compile-time stage. From: leon zadorin To: gcc-help@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-11/txt/msg00029.txt.bz2 On 11/4/11, Vincent Lefevre wrote: > On 2011-11-04 01:28:00 +1100, leon zadorin wrote: >> On 11/3/11, Vincent Lefevre wrote: >> > I'd say that this wouldn't be much useful, because similar problems >> > can also occur at run time, and if you use options like -ffast-math, >> > you won't be able to tell whether your program works correctly... >> > unless you can prove that no overflows (etc.) can occur. But if you >> > can do that, you no longer need GCC to do this for you for the >> > particular case of compile-time calculations. >> >> But as I had mentioned in my original post -- there is a way to detect >> this at runtime, even if compiler optimizes based on presumptions of >> finite math etc implied by -ffast-math. > > Hmm... Yes, this should be possible. But I'm not sure this is easy. > The reason is that the rounding mode used at compile time may be > different than the rounding mode used at run time, so that there > may be an overflow when an expression is evaluated at compile time > (in which case the compile-time evaluation is discarded, AFAIK[*]) > while there will be no overflows at run time. In such a case, a > warning could be regarded as a bug. > > [*] From Kaveh R. GHAZI in the gcc mailing-list on 2008-01-03: > > "So I tried that, but mpfr_gamma on that value sets the global underflow > flag. If overflow/underflow are set by mpfr, GCC will intentionally > bypass folding. So this particular case is not something I can use." Aha, now this is very interesting :-) :-) With very aggressive optimization options (-ffast-math et al) gcc 4.6.1 (from my memory - I'm typing away from coding box), the following code: float x(::std::numeric_limits::max()); float y(x * 2); appeared to produce an Inf at compile time (eg the runtime detection of fpu status was not sensing overflow, but indeed the value of y when printed or examined otherwise was Inf)... When, however, an extern function, taking address of x in its signature yet doing nothing (in implementation in a different translation unit compiled without -FL to but with -fno-lto etc), was called between the above 2 lines, the run-time fpu status was correctly showing an overflow after y evaluation... So... I am happy to have it either way: a) compiler does do it at compile time (differences wrt run-time calculations are not an issue as those will always be there in pretty much all of the "unsafe optimization options" for the floating point math - like associative grouping, rounding modes, hardware fpu register architecture which may not be ieee standard anyway and have a different accumulating precision loss when temps are being stored in registers, etc...); ... but it should emit a diagnostic (if one is uncomfortable calling it a warning, the just call it a verbosity output, just like the -ftree-vectorizer-verbose meaning). b) compiler does not do it at compile-time if its calculated evaluation yields non-finite value (although things like Nan are obtainable vis div by zero legitimately.. I think... but I digress); ... but may be it does not do this currently if things like -ffinite-math are being set? Personally I would suggest, ever so slightly, the former option - verbosity output. The compiler, from the info you had quoted, does already sense the non-finite states of its evaluations, and if it does decide to go ahead with writing the value at compile-time (eg may because the optimization options infer this), then might as well print a message about it... and if the semantics of a warning are too drastic, then just call it a verbosity-related output :-) Of course, I must say - I am way out of my depth here wrt compiler internals... I know nothing... I shall retest the aforementioned code as soon as I get a chance... best regards leon zadorin. > -- > Vincent Lef=E8vre - Web: > 100% accessible validated (X)HTML - Blog: > Work: CR INRIA - computer arithmetic / Ar=E9naire project (LIP, ENS-Lyon) >