On Sun, 26 Jun 2011 13:30:41 +0200
Volker Armin Hemmann <volkerarmin@...> wrote:

> Believe it or not, this tarball is straight from hell.
> 
> 1. do not tar-bomb. Pack directories not files.

This one was my fault, but I didn't want to complicate the instructions
for those who may not have much background in these things.  That is
why I specified to first create a directory and then to unpack within
that directory.

> 2. the permissions are a nightmare.
> 3. I accidentally unpacked in /tmp and your tarball tried to set UTIME and the 
> permissions of the parent directory. WTF?

These are the fault of the original programmers.  Such messes were common
back in 1995.

> 4. have you checked that the errors you are seeing are really errors?
> Just remember that stupidity about 80bit/64bit/128bit floats all around.
> 5. http://gcc.gnu.org/wiki/FloatingPointMath

You forgot to mention decimal floating point which is yet another
variant.

This particular test is configured to test double precision (64-bit) in
C only which seems to be the standard on Linux.  On Intel Linux at least,
64-bit FP is done entirely in hardware.

The IEEE 754 standard was set way back in 1985.  Already it may becoming
obsolete (just like IPv4).  Hardware is getting more capable and can
allow for greater precisions.  Also, we are now seeing hardware for 
decimal floating point which will be a boon to financial software.

It should also be noted that the emerging field of computation
with GPUs does not have any floating point standards at all.
With GPU programming, floating point operations are similar
to the chaos that ruled in the CPU world before IEEE 754.

> 
> without additional settings gcc 4.5.2:
> 

>
> /tmp/usbtest/clib_DP.output: ucbtest UCBFAIL in cabsd at line 701 for double 
>

Thanks for this!  It does seem to verify that gcc-4.5.2 does mangle the code
for this particular test.

Frank Peters