bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnubg] compiling with optimization


From: Jim Segrave
Subject: Re: [Bug-gnubg] compiling with optimization
Date: Wed, 19 Nov 2003 18:15:45 +0100
User-agent: Mutt/1.4i

On Wed 19 Nov 2003 (14:40 +0000), Jon Kinsey wrote:
> At 14:28 19/11/2003, Jim Segrave wrote:
> >On Wed 19 Nov 2003 (08:17 +0000), Jon Kinsey wrote:
> >> At 00:14 19/11/2003, ?ystein Johansen wrote:
> >> >Nardy Pillards wrote:
> >> >>>I guess Nardy's builds also use -O3. Nardy?
> >> >>They did use 03, but changed it to -0 when 03 gave probs with 3D.
> >> >
> >> >I just used -O3 on a build with the 3D board here, and I didn'y have any
> >> >problems. (Though I have updated my 3D driver)
> >>
> >> I've used -O3 too with no problems.  What problems did you get Nardy?
> >>
> >> Also Achim, did you try -O (or -O1), perhaps it's also similiar in 
> >speed to
> >> -O2/3?
> >
> >I think we also saw a problem with the MAC version where calculating
> >shadows was broken, reducing from O3 fixed it.
> 
> There where problems, but not to do with O3 - as far as I know.  I remember 
> Nardy mentioning that -Os messes up the met table or something, I've not 
> looked at any optimization problems (for the 3d code).

Hmm - I have an email from Olivier Baur:

On Tue 19 Aug 2003 (18:14 +0200), Olivier Baur wrote:
> Le mardi, 19 ao? 2003, ? 15:34 Europe/Paris, Jim Segrave a ?crit :
> 
> >I must be missing something here: sin(pi/2) = 1
> >
> >latitude = (float)sin(angle2) * lip;
> >
> >so latitude = lip
> >new_radius = (float)sqrt((lip * lip) - (latitude * latitude));
> >so
> >new_radius = (float) sqrt(lip*lip - lip*lip) =
> >should be sqrt( 0 ), except for rouding errors, but should never lead
> >to NAN.
> >
> >The only way I can see this going wrong is some compiler optimisation
> >causing problems for the FPU. Could you try the following patch which
> >should give an assert failure (and hence should allow a debugger to
> >see the values in question):
> 
> Well, you were right, it is an optimisation issue -- the problem 
> disappears when I compile with -O0.
> 
> I've added some debug-code to the proc to see what arg is passed to 
> sqrt, writing:
> 
>   float d2;
>   latitude = (float)sin(angle2) * lip;
>   d2 = (lip * lip) - (latitude * latitude);
>   new_radius = (float)sqrt(d2);
> 
> With -O0 I get what expected:
> 
>   latitude = 1.500000e-02
>   lip = 1.500000e-02
>   d2 = 0.000000e+00
> 
> But with -O2 I get:
> 
>   latitude = 1.500000e-02
>   lip = 1.500000e-02
>   d2 = -7.194467e-12  (!!! negative, nonzero !!!)
> 
> I've tried to isolate the proc in a simple, standalone app, but the bug 
> doesn't show up there.
> 
> I'll investigate the case further when I have more time.
> 



-- 
Jim Segrave           address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]