From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11817 invoked by alias); 24 Jun 2008 20:13:04 -0000 Received: (qmail 11018 invoked by uid 48); 24 Jun 2008 20:12:20 -0000 Date: Tue, 24 Jun 2008 20:13:00 -0000 Message-ID: <20080624201220.11017.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug rtl-optimization/323] optimized code gives strange floating point results In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "pepalogik at seznam dot cz" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2008-06/txt/msg01445.txt.bz2 ------- Comment #117 from pepalogik at seznam dot cz 2008-06-24 20:12 ------- (In reply to comment #116) > > Yes, but this requires quite a complicated workaround (solution (4) in my > > comment #109). > > The problem is on the compiler side, which could store every result of a cast > or an assignment to memory (this is inefficient, but that's what you get with > the x87, and the ISO C language could be blamed too for *requiring* something > like that instead of being more flexible). > > > So you could say that the IEEE754 double precision type is available even on > > a processor without any FPU because this can be emulated using integers. > > Yes, but a conforming implementation would be the processor + a library, not > just the processor with its instruction set. > > > Moreover, if we assess things pedantically, the workaround (4) still doesn't > > fully obey the IEEE single/double precision type(s), because there remains the > > problem of double rounding of denormals. > > As I said, in this particular case (underflow/overflow), double rounding is > allowed by the IEEE standard. It may not be allowed by some languages (e.g. > XPath, and Java in some mode) for good or bad reasons, but this is another > problem. OK, thanks for explanation. I think now it's clear. > > I quote, too: > > "Applies To > > Microsoft® Visual C++®" > > Now I assume that it follows the MS-Windows API (though nothing is certain with > Microsoft). And the other compilers under MS-Windows could (or should) do the > same thing. By a lucky hit, I have found this in the GCC documentation: " -mpc32 -mpc64 -mpc80 Set 80387 floating-point precision to 32, 64 or 80 bits. When '-mpc32' is specified, the significands of results of floating-point operations are rounded to 24 bits (single precision); '-mpc64' rounds the the significands of results of floatingpoint operations to 53 bits (double precision) and '-mpc80' rounds the significands of results of floating-point operations to 64 bits (extended double precision), which is the default. When this option is used, floating-point operations in higher precisions are not available to the programmer without setting the FPU control word explicitly. [...]" So GCC sets extended precision by default. And it's easy to change it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323