Using OS X Snow Leopard I get the same dt_arith failure from hdf5-1.8.11
using gcc-4.8 as I did for hdf5-1.8.10 using llvm-gcc-4.2

This is a 64-bit build:
$ file hdf5-1.8.11/src/H5.o
hdf5-1.8.11/src/H5.o: Mach-O 64-bit object x86_64

$ grep 'Compiler' BuildIt_hdf5*.log
BuildIt_hdf5-1.8.11.log:                     C Compiler:
/opt/local/bin/gcc-mp-\
4.8
BuildIt_hdf5-1.8.11.log:                     C Compiler:
/opt/local/bin/gcc-mp-\
4.8
BuildIt_hdf5_1.8.10.log:                     C Compiler:
/opt/local/bin/llvm-gc\
c-4.2 ( (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build))


The test that fails on Cygin passes here:

$ grep 'Testing hard signed char -> long double conversions'
 BuildIt_hdf5*.log
BuildIt_hdf5-1.8.11.log:Testing hard signed char -> long double
conversions                    PASSED
BuildIt_hdf5-1.8.10.log:Testing hard signed char -> long double
conversions               PASSED

But there are other problems:

$ grep terminated BuildIt_hdf5*.log
BuildIt_hdf5-1.8.11.log:Testing hard normalized long double -> signed char
conversions        Command terminated abnormally.
BuildIt_hdf5-1.8.10.log:Testing hard normalized long double -> signed char
conversions        Command terminated abnormally.




On Wed, May 22, 2013 at 2:47 AM, marco atzeri <marco.atz...@gmail.com>wrote:

> Hi,
> testing 1.8.11 on the new cygwin64 platform with
>
>  $ gcc --version
> gcc (GCC) 4.8.0
> Copyright (C) 2013 Free Software Foundation, Inc.
>
>
> I have alot of long double conversion,
> but the output is a bit strange:
> ------------------------------**------------------------------**---------
> Testing hard signed char -> long double conversions *FAILED*
>     elmt 0:
>         src =  01                     1
>         dst =  ff 80 7f 40 3f 20 3f ff 80 00 00 00 00 00 00 00
>  1.000000
>         ans =  00 00 00 00 00 00 3f ff 80 00 00 00 00 00 00 00
>  1.000000
>
> [cut]
>     elmt 87:
>         src =  00 00 0f ff ff ff ff ff        17592186044415
>         dst =  ff ff 80 00 00 00 40 2a ff ff ff ff ff f0 00 00
> 17592186044415.000000
>         ans =  00 00 00 00 00 00 40 2a ff ff ff ff ff f0 00 00
> 17592186044415.000000
>     maximum failures reached, aborting test...
>     (dst is library's conversion output. ans is compiler's conversion
> output.)
> ------------------------------**------------------------------**----------
>
> But in  theory this case is handled by
>
> ------------------------------**-- dt_arith.c ----------------------
>         /* Make certain that there isn't some weird number of destination
> bits */
>         assert(dst_nbits%8==0);
>
>         /* For Intel machines, the size of "long double" is 12 bytes,
> precision
>          * is 80 bits; for AMD processors, the size of "long double" is 16
> bytes,
>          * precision is 80 bits.  During hardware conversion, the last few
> unused
>          * bytes may have garbage in them.  Clean them out with 0s before
> compare
>          * the values.
>          */
> #if H5_SIZEOF_LONG_DOUBLE !=0
>         if(dendian==H5T_ORDER_LE && dst_type==FLT_LDOUBLE) {
>             unsigned int q;
>             for(q=dst_nbits/8; q<dst_size; q++) {
>                 buf[j*dst_size+q] = 0x00;
>             }
>         }
> ------------------------------**------------------------------**--------
>
> any one seeing the same issue on other 64bit platform ?
>
> Regards
> Marco
>
> ______________________________**_________________
> Hdf-forum is for HDF software users discussion.
> Hdf-forum@hdfgroup.org
> http://mail.hdfgroup.org/**mailman/listinfo/hdf-forum_**hdfgroup.org<http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org>
>



-- 
George N. White III <aa...@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
_______________________________________________
Hdf-forum is for HDF software users discussion.
Hdf-forum@hdfgroup.org
http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org

Reply via email to