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