[Top][All Lists]
[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
- [Bug-gnubg] compiling with optimization, Achim Mueller, 2003/11/18
- Re: [Bug-gnubg] compiling with optimization, Øystein Johansen, 2003/11/18
- Re: [Bug-gnubg] compiling with optimization, Nardy Pillards, 2003/11/18
- Re: [Bug-gnubg] compiling with optimization, Øystein Johansen, 2003/11/18
- Re: [Bug-gnubg] compiling with optimization, Jon Kinsey, 2003/11/19
- Re: [Bug-gnubg] compiling with optimization, Jim Segrave, 2003/11/19
- Re: [Bug-gnubg] compiling with optimization, Jon Kinsey, 2003/11/19
- Re: [Bug-gnubg] compiling with optimization,
Jim Segrave <=
- Re: [Bug-gnubg] compiling with optimization, Jon Kinsey, 2003/11/20
Re: [Bug-gnubg] compiling with optimization, Holger, 2003/11/18