Re: floating point: weird behaviour of gcc-2.95

[juggy at gmx dot net]

OK, it seems I need to make it clearer.
1.) I write Ansi-C code. I don't care to write any ASM or such since
this code is supposed to work on as many OS as possible
2.) I do NOT intend to "test to see whether x87 operations are carried
out in 53bit precision mode"

It's just that for debugging and checking an ap I use switches like (-pg
-g etc. - no -Ox, x>0, whatsoever) at compile time. Since the software
computationally expensive I naturally want to improve the speed as much
as possible, so I use optimization switches. Now, what did I do?
1.) check my software on test cases and real world data without optimization
2.) when 1. worked I decided to optimize to be able to run checks on
more data
3.) the exact same data with the exact same program screwed up on the
linux boxes here. Accidentally I tested it on a BSD system as well and
it went alright. I would not expect THAT to happen - "if I misunderstand
the optimizations of GCC they should render the same results on te same
type of processors (all p3 or p4 around here)" I thought :-(

I tried switches like -fno-fast-math -fmath-storage.. (or whatever) to
check whether an optimization method is turned on that causes this
behaviour. I didn't find any definite cause for it. :-/
I also tried compiling with gcc-2.95.4 and gcc-3.2.1 on the exact same
(Linux 2.4.20, P3) system with these commands:
- gcc-3.2.1 -lm -O[0,1,2] -o soft *.c
- gcc-2.95.4 -lm -O[0,1,2] -o soft *.c
The only thing that gave different (=wrong) results was
gcc-2.95.4 -lm -O2 -o soft *.c

I hope this is clearer now. If you tell me that gcc-2.95.[3|4] on Linux
turns on an optimization when using -O2 that is not used on BSD or with
gcc-3.2.1, I am happy. :-) And I'll probably delighted if you could fill
  me in on how to get the same behaviour on Linux systems with
gcc-2.95.[3|4] -O2 as gcc-2.95.[3|4] -O1 or gcc-3.2.1 -O[1|2] ^_-

Cheers

P.S.: Sorry if I send this twice - at first I just replied and it didn't 
go to the list

Tim Prince wrote:
> On Friday 17 January 2003 03:29, juggy@gmx.net wrote:
>
> > Hi there,
> >
> > I recently noticed an odd behaviour of gcc. I searched the archives, but
> > I didn't find anything that really looks like this.
> > I am currently writing software that must be as numerically stable as
> > possible. Now the problem is that on Linux-Machines with gcc-2.95.3 and
> > gcc-2.95.4 (I didn't have other versions to check) using the switch -O2
> > results in inaccuracies (i.e. a double variable never becomes 0) whilst
> > -O1 is still alright.
> > At first I thought I might be using the switches in a wrong way, but
> > when I checked on a FreeBSD system (gcc-2.95.3) with the exactly same
> > program and the same switches it worked fine. I also tried switches like
> > -fno-fast-math and such, but none seemed to solve the problem.
> > Afterwards I checked with gcc-3.2.1, and everything worked fine with -O2.
> > Maybe I am missing something about using the correct switches, but I
> > think it is very odd that gcc on BSD and gcc on Linux show this
> > different a behaviour. I'd really appreciate if anyone could elighten me
> > on this issue.
> If you're testing to see whether x87 operations are carried out in 53-bit 
> precision mode, why not say so?   No, there's no switch to pass to linux 
> run-time libraries to change precision mode, but you could use the asm() 
> functions.  WIth gcc-3.2.1, you do have switches to select x87, SSE, or SSE2 
> code generation, so you can control precision of intermediate operations that 
> way.  If you've truly come across something which isn't in the archives, you 
> certainly haven't bothered to explain it.