[svn-r12425] Purpose: Bug fix

Description: Data conversion from long double to (unsigned) long long
returns some incorrect values on Mac OS 10.4 and SGI IRIX64 6.5.  The
conversions start to go wrong when the long double is
20041683600089727.779961 (0x4351ccf385ebc8a0bfcc2a...).  If adjusting
the values higher by assigning 0x...c8a0cf... or 0x...c8a0df..., the
converted values go wild.

Solution: Detect this error in configure.in and disable compiler
conversions from long double to (unsigned) long long for Mac OS 10.4
and IRIX64 6.5.

Platforms tested: h5committest, Mac OS 10.4, and IRIX64 6.5.

1 files changed, 63 insertions, 0 deletions

diff --git a/configure.in b/configure.in
index 7afc0fd..c8bd31d 100644
--- a/configure.in
+++ b/configure.in
@@ -3094,6 +3094,69 @@ else
 fi
 
 dnl ----------------------------------------------------------------------
+dnl Set the flag to indicate that the machine can accurately convert
+dnl 'long double' to '(unsigned) long long' values.  (This flag should be set for 
+dnl all machines, except for Mac OS 10.4 and SGI IRIX64 6.5.  When the bit sequence
+dnl of long double is 0x4351ccf385ebc8a0bfcc2a3c..., the values of (unsigned)long long
+dnl start to go wrong on these two machines.  Adjusting it higher to 
+dnl 0x4351ccf385ebc8a0dfcc... or 0x4351ccf385ebc8a0ffcc... will make the converted 
+dnl values wildly wrong.  This test detects this wrong behavior and disable the test.  
+dnl
+AC_MSG_CHECKING([if correctly converting long double to (unsigned) long long values])
+
+if test ${ac_cv_sizeof_long_double} = 0; then
+   hdf5_ldouble_to_llong_accurate=${hdf5_ldouble_to_llong_accurate=no}
+else
+   AC_CACHE_VAL([hdf5_ldouble_to_llong_accurate],
+        [AC_TRY_RUN([
+        int main(void)
+        {
+            long double         ld = 20041683600089727.779961L;
+            long long           ll;
+            unsigned long long  ull;
+            unsigned char       s[16];
+            int                 ret = 0;
+            
+            if(sizeof(long double) == 16) {
+                /*make sure the long double type is the same as the failing type 
+                 *which has 16 bytes in size and 11 bits of exponent.  If it is,
+                 *the bit sequence should be like below.  It's not 
+                 *a decent way to check but this info isn't available. */   
+                memcpy(s, &ld, 16);
+                if(s[0]==0x43 && s[1]==0x51 && s[2]==0xcc && s[3]==0xf3 &&
+                    s[4]==0x85 && s[5]==0xeb && s[6]==0xc8 && s[7]==0xa0 &&
+                    s[8]==0xbf && s[9]==0xcc && s[10]==0x2a && s[11]==0x3c) {
+
+                    /*slightly adjust the bit sequence (s[8]=0xdf).  The converted
+                     *values will go wild on Mac OS 10.4 and IRIX64 6.5.*/ 
+                    s[0]=0x43; s[1]=0x51; s[2]=0xcc; s[3]=0xf3;
+                    s[4]=0x85; s[5]=0xeb; s[6]=0xc8; s[7]=0xa0;
+                    s[8]=0xdf; s[9]=0xcc; s[10]=0x2a; s[11]=0x3c;
+                    s[12]=0x3d; s[13]=0x85; s[14]=0x56; s[15]=0x20;
+
+                    memcpy(&ld, s, 16);
+                    ll = (long long)ld;
+                    ull = (unsigned long long)ld;
+                    
+                    if(ll != 20041683600089728 || ull != 20041683600089728)
+                        ret = 1;
+                }    
+            }    
+    done:
+            exit(ret);
+        }
+        ], [hdf5_ldouble_to_llong_accurate=yes], [hdf5_ldouble_to_llong_accurate=no],)])
+fi
+
+if test ${hdf5_ldouble_to_llong_accurate} = "yes"; then
+  AC_DEFINE([LDOUBLE_TO_LLONG_ACCURATE], [1],
+            [Define if your system can convert long double to (unsigned) long long values correctly.])
+  AC_MSG_RESULT([yes])
+else
+  AC_MSG_RESULT([no])
+fi
+
+dnl ----------------------------------------------------------------------
 dnl Set some variables for general configuration information to be saved
 dnl and installed with the libraries.
 dnl