Re: where to discuss problems with IEEE 754 standard on x86 architecture?

Re: where to discuss problems with IEEE 754 standard on x86 architecture?

[Nick Maclaren]

I was being stupid.  Sorry.  My reply was correct but unhelpful.

You were using -mfpmath=387 (possible as the default), and that uses
Intel native arithmetic, which is NOT standard IEEE 754 double, but
an extended format.

If you use -mfpmath=sse, you will get what you expect.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

Re: where to discuss problems with IEEE 754 standard on x86 architecture?

[Petr Savicky]

> You were using -mfpmath=387 (possible as the default), and that uses
> Intel native arithmetic, which is NOT standard IEEE 754 double, but
> an extended format.
> 
> If you use -mfpmath=sse, you will get what you expect.
> 
Thank you for your reply. This explains the problem.

However, solving the problem seems to be harder.
I tried "gcc -mfpmath=sse", but obtained the warning:
 SSE instruction set disabled, using 387 arithmetics.

gcc version: 3.3.3
uname -m -p -i: i686 i686 i386
/proc/cpuinfo:
  vendor_id   : GenuineIntel
  cpu family  : 15
  model       : 2
  model name  : Intel(R) Xeon(TM) CPU 2.80GHz

I obtained the same on another computer with
gcc version: 4.1.0
uname -m -p -i: i686 i686 i386
/proc/cpuinfo:
  vendor_id   : GenuineIntel
  cpu family  : 6
  model       : 8
  model name  : Celeron (Coppermine)

man gcc says: For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches
               to enable SSE extensions and make this option effective.
The choices for cpu-type are the same as for -mtune. 
-mtune=cpu-type has possible values itanium, itanium1, merced, itanium2, and mckinley
   none of which seems to fit my computers.

With "gcc -mfpmath=sse -msse" I obtained no warning/error, but the program
behaves in the old wrong way.

So, I think that SSE is not available on my computers. Is this correct?

All the best, Petr.

Re: where to discuss problems with IEEE 754 standard on x86 architecture?

[Nick Maclaren]

> > You were using -mfpmath=387 (possible as the default), and that uses
> > Intel native arithmetic, which is NOT standard IEEE 754 double, but
> > an extended format.
> > 
> > If you use -mfpmath=sse, you will get what you expect.
> 
> Thank you for your reply. This explains the problem.
> 
> However, solving the problem seems to be harder.
> I tried "gcc -mfpmath=sse", but obtained the warning:
>  SSE instruction set disabled, using 387 arithmetics.

I have never discovered a gcc switch to enable 'proper' IEEE 754
arithmetic.  -ffloat-store does something, at the expense of slowing
down code.

There are reasons for this.  IEEE 754 is a hardware specification and,
in over 20 years, has neve been supported by programming languages.
The IEEE 754 fanatics claim that it is the language and compiler
people being uncooperative, but it really is due to the fact that
the IEEE 754 standard is very unsuitable for implementing in any
high-level language I know of.  It also has major numerical RAS
flaws, but that's another matter.

C99 has taken in on board, but is a complete crock, and only Sun
(and POSSIBLY some Microsoft-only compilers) support that aspect.

You should learn how to write numeric code that is independent of
the arithmetic, which will also usually make it more robust.  That
is what we used to do 30+ years ago, when there was a LOT more
variation than there is today.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

Re: where to discuss problems with IEEE 754 standard on x86 architecture?

[Brian Dessent]

Petr Savicky wrote:

> With "gcc -mfpmath=sse -msse" I obtained no warning/error, but the program
> behaves in the old wrong way.

Try with -O2 and you'll see vastly different results.  Without any -O
you're telling gcc not to do any optimization whatsoever, and many, many
passes are just never run in that case so lots of stuff won't work. 
It's possible that none of -mfpmath  or -ffast-math or -ffloat-store or
-mpc32/-mpc64/-mpc80 et al. don't work without optimization passes
enabled.  But you'd have to look at the code and documentation to find
out for sure.

Brian

Re: where to discuss problems with IEEE 754 standard on x86 architecture?

[Tim Prince]

Petr Savicky wrote:
>> You were using -mfpmath=387 (possible as the default), and that uses
>> Intel native arithmetic, which is NOT standard IEEE 754 double, but
>> an extended format.
>>
>> If you use -mfpmath=sse, you will get what you expect.
>>
>>     
> Thank you for your reply. This explains the problem.
>
> However, solving the problem seems to be harder.
> I tried "gcc -mfpmath=sse", but obtained the warning:
>  SSE instruction set disabled, using 387 arithmetics.
>
> gcc version: 3.3.3
> uname -m -p -i: i686 i686 i386
> /proc/cpuinfo:
>   vendor_id   : GenuineIntel
>   cpu family  : 15
>   model       : 2
>   model name  : Intel(R) Xeon(TM) CPU 2.80GHz
>
> I obtained the same on another computer with
> gcc version: 4.1.0
> uname -m -p -i: i686 i686 i386
> /proc/cpuinfo:
>   vendor_id   : GenuineIntel
>   cpu family  : 6
>   model       : 8
>   model name  : Celeron (Coppermine)
>
> man gcc says: For the i386 compiler, you need to use -march=cpu-type, -msse or -msse2 switches
>                to enable SSE extensions and make this option effective.
> The choices for cpu-type are the same as for -mtune. 
> -mtune=cpu-type has possible values itanium, itanium1, merced, itanium2, and mckinley
>    none of which seems to fit my computers.
>
> With "gcc -mfpmath=sse -msse" I obtained no warning/error, but the program
> behaves in the old wrong way.
>
> So, I think that SSE is not available on my computers. Is this correct?
>
>   
Why didn't you follow the advice you quoted? 
gcc -march=pentium4 -mfpmath=sse
When you compile code for pentium2, of course SSE is not available to 
the compiler.

Re: where to discuss problems with IEEE 754 standard on x86 architecture?

[Petr Savicky]

> Why didn't you follow the advice you quoted? 
> gcc -march=pentium4 -mfpmath=sse
> When you compile code for pentium2, of course SSE is not available to 
> the compiler.

Thank you very much.
  gcc -march=pentium4 -mfpmath=sse
seems to work correctly. The threshold is now 1.5*2^{-52} as
it should be.

I did not try -march=pentium4 before, since man gcc contains several
descriptions of -march for each architecture class separately and I did
not reach the right one.

Thanks to all of you, who send me advice.

Petr.

Re: where to discuss problems with IEEE 754 standard on x86 architecture?

[Nick Maclaren]

Petr Savicky <savicky@cs.cas.cz> wrote:
>
> Can anybody help me to find the right place to discuss the problems
> related to IEEE 754 standard for floating point numbers on x86 (IA-32)?

Well, I could, but they wouldn't be terribly pleased.  Your error is
to assume that IEEE 754 applies to composite operations, whereas it
actually applies to each basic one in turn.  To see what is going on,
you should print out the balues in binary, octal or hexadecimal, for
each sub-operation.

As far as I can see, gcc is doing nothing wrong.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679

where to discuss problems with IEEE 754 standard on x86 architecture?

[Petr Savicky]

Can anybody help me to find the right place to discuss the problems
related to IEEE 754 standard for floating point numbers on x86 (IA-32)?

The following code
  #include <stdio.h>
  
  int main(int argc, char *argv[]) {
      double x,y,z,m=1.0;
      for (int i=0; i<52; i++) { m *= 2.0; }
  
      x = 1.5 - 1.0/4096.0 - 1.0/m;
      y = 1.5 - 1.0/4096.0;
  
      z = 1.0 + 1.0/m*x;
      printf("%f\n",m*(z-1.0));
  
      z = 1.0 + 1.0/m*y;
      printf("%f\n",m*(z-1.0));
  }
produces output
  1.000000
  2.000000
on x86 (IA-32) processor. In my opinion, this implies that IA-32 processor
does not follow IEEE 754 exactly, since the closest representable
value to both 1.0 + 1.0/m*x and 1.0 + 1.0/m*y is z = 1.0 + 1.0/m
and not z = 1.0 + 2.0/m, which is obtained in the second case.

Am I right? If yes, I think that the problem is known. Are there web
pages or other resources on this problem?

Thank you very much for any information.

All the best, Petr.

RE: where to discuss problems with IEEE 754 standard on x86 architecture?

[John (Eljay) Love-Jensen]

Hi Petr,

On my x86 (IA-32) system the results were:

1.000000
1.000000

HTH,
--Eljay

Re: where to discuss problems with IEEE 754 standard on x86 architecture?

[Andrew Haley]

Petr Savicky writes:
 > Can anybody help me to find the right place to discuss the problems
 > related to IEEE 754 standard for floating point numbers on x86 (IA-32)?
 > 
 > The following code
 >   #include <stdio.h>
 >   
 >   int main(int argc, char *argv[]) {
 >       double x,y,z,m=1.0;
 >       for (int i=0; i<52; i++) { m *= 2.0; }
 >   
 >       x = 1.5 - 1.0/4096.0 - 1.0/m;
 >       y = 1.5 - 1.0/4096.0;
 >   
 >       z = 1.0 + 1.0/m*x;
 >       printf("%f\n",m*(z-1.0));
 >   
 >       z = 1.0 + 1.0/m*y;
 >       printf("%f\n",m*(z-1.0));
 >   }
 > produces output
 >   1.000000
 >   2.000000
 > on x86 (IA-32) processor. In my opinion, this implies that IA-32 processor
 > does not follow IEEE 754 exactly, since the closest representable
 > value to both 1.0 + 1.0/m*x and 1.0 + 1.0/m*y is z = 1.0 + 1.0/m
 > and not z = 1.0 + 2.0/m, which is obtained in the second case.
 > 
 > Am I right? If yes, I think that the problem is known. Are there web
 > pages or other resources on this problem?

Yes.  See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323

Andrew.