Your message dated Sun, 6 Jul 2003 09:24:22 -0400
with message-id <[EMAIL PROTECTED]>
and subject line Bug#175809: Strange or incorrect floating point behaviour
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 8 Jan 2003 09:16:43 +0000
>From [EMAIL PROTECTED] Wed Jan 08 03:16:43 2003
Return-path: <[EMAIL PROTECTED]>
Received: from sphinx.cosy.sbg.ac.at [141.201.2.68]
by master.debian.org with esmtp (Exim 3.12 1 (Debian))
id 18WCKI-0004Du-00; Wed, 08 Jan 2003 03:16:42 -0600
Received: from ettin.cosy.sbg.ac.at (ettin.cosy.sbg.ac.at [141.201.150.26])
by sphinx.cosy.sbg.ac.at (Postfix) with ESMTP id 939933DEA9
for <[EMAIL PROTECTED]>; Wed, 8 Jan 2003 10:16:36 +0100 (MET)
Received: by ettin.cosy.sbg.ac.at (Postfix, from userid 2046)
id CF0321C893; Wed, 8 Jan 2003 10:16:35 +0100 (CET)
Date: Wed, 8 Jan 2003 10:16:35 +0100
To: [EMAIL PROTECTED]
Subject: Strange or incorrect floating point behaviour
Message-ID: <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i
From: [EMAIL PROTECTED] (Gerhard Wesp)
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-7.2 required=5.0
tests=SIGNATURE_SHORT_DENSE,SPAM_PHRASE_00_01,USER_AGENT,
USER_AGENT_MUTT
version=2.41
X-Spam-Level:
Package: g++-3.2
Version: 3.2.2 20021212 (Debian prerelease)
Note that this problem most likely is present in other g++ versions, and
also, in similar forms, in other gcc languages.
It was discussed in comp.lang.c++.moderated, cf.
news:<[EMAIL PROTECTED]> and the followup postings.
Posters suggested it might be a bug in the implementation of
-ffloat-store and/or related to floating point expressions evaluated at
compile-time and at runtime with different precisions.
Mathematically, a >= b implies ka >= kb for k >= 0. While I'm well
aware that not all properties of the reals carry over to floating point
arithmetic, I certainly would expect this *particular* implication to
carry over. However, g++ -O3 thinks otherwise.
In the code below, the last assertion fails under certain circumstances.
It's these circumstances which make the behaviour really mysterious:
The assertion does *not* fail if *any* of the following conditions is
satisfied:
1) The bound() template is replaced by a function. (Change the #if 1 to
#if 0.)
2) Lines (1) or (2) are commented out.
3) 2.5 is replaced by other values, e.g. 4.
4) -O2 is specified instead of -O3 (it *does*, however, fail with
-O2 -ffloat-store).
My first guess was that this has something to do with internal usage of
80 bit floating point values, but this doesn't go well with observation
4).
#include <cassert>
#if 1
template< typename T > inline void bound( T & x , T const& u
) {
#else
inline void bound( double& x , double const& u
) {
#endif
assert( 1. <= u ) ; // (1)
if( x < 1. ) { x = 1. ; } // (2)
if( x > u ) { x = u ; }
}
int main() {
const double u = 2.1 ;
double x = 3 ;
bound( x , u ) ;
assert( u >= x ) ;
assert( 2.5*u >= 2.5*x ) ; // fails!!!
}
--
| voice: +43 (0)676 6253725 *** web: http://www.cosy.sbg.ac.at/~gwesp
|
| Passts auf, seid's vuasichdig, und lossds eich nix gfoin!
| -- Dr. Kurt Ostbahn
---------------------------------------
Received: (at 175809-done) by bugs.debian.org; 6 Jul 2003 13:24:45 +0000
>From [EMAIL PROTECTED] Sun Jul 06 08:24:42 2003
Return-path: <[EMAIL PROTECTED]>
Received: from crack.them.org [146.82.138.56]
by master.debian.org with esmtp (Exim 3.35 1 (Debian))
id 19Z9VS-0003Hp-00; Sun, 06 Jul 2003 08:24:42 -0500
Received: from dsl093-172-017.pit1.dsl.speakeasy.net
([66.93.172.17] helo=nevyn.them.org ident=mail)
by crack.them.org with asmtp (Exim 3.12 #1 (Debian))
id 19Z9WA-0003ya-00; Sun, 06 Jul 2003 08:25:26 -0500
Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian))
id 19Z9V9-0001Y6-00; Sun, 06 Jul 2003 09:24:23 -0400
Date: Sun, 6 Jul 2003 09:24:22 -0400
From: Daniel Jacobowitz <[EMAIL PROTECTED]>
To: Matthias Klose <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], Gerhard Wesp <[EMAIL PROTECTED]>
Subject: Re: Bug#175809: Strange or incorrect floating point behaviour
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL
PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.1i
Delivered-To: [EMAIL PROTECTED]
X-Spam-Status: No, hits=-15.5 required=4.0
tests=BAYES_20,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,
REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MUTT
autolearn=ham version=2.53-bugs.debian.org_2003_06_27
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 2.53-bugs.debian.org_2003_06_27
(1.174.2.15-2003-03-30-exp)
Yes, closing.
On Sun, Jul 06, 2003 at 11:32:29AM +0200, Matthias Klose wrote:
> Daniel, should this report be closed?
>
> Daniel Jacobowitz writes:
> > On Fri, Jan 10, 2003 at 11:58:33AM +0100, Gerhard Wesp wrote:
> > > > Do you get the expected results if you do this?
> > >
> > > Yes and no.
> > >
> > > I include a modified example.
> > >
> > > The assertion fails if compiled with -O3 -ffloat-store -DA, it doesn't
> > > if compiled without the -DA. So it seems to depend on where the
> > > assignments take place.
> >
> > > #if defined( A )
> > > double ku ;
> > > double kx ;
> > > assert( ( ku = 2.5 * u ) >= ( kx = 2.5 * x ) ) ; // fails.
> > > #else
> > > double ku = 2.5 * x ;
> > > double kx = 2.5 * u ;
> > > assert( ku >= kx ) ; // doesn't fail.
> > > #endif
> >
> > Yup, that's C for you. The former uses the value of 2.5*u, the latter
> > uses the value of ku. You can see how this works by declaring ku
> > volatile and looking at the assembly; it'll be reloaded in the second
> > case but not the first.
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
