-------------------------------- 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 ?
Failures with the dt_arith test have been reported years ago, but it seems fixing it is not at the top of anyone's list.
The test invokes undefined behaviour, and modern optimizing compilers like gcc 4.8 are more and more performing optimizations assuming undefined behaviour does not occur.
Cheers,
···
On Wed, 22 May 2013 07:47:25 +0200, marco atzeri said:
testing 1.8.11 on the new cygwin64 platform with
--
____________________________________________________________
Sean McBride, B. Eng sean@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
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.
------------------------------**-- 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 ?
Thanks Sean ,
I saw on another package the gcc-4.8 optimization is producing wrong
output so I was just wondering if it was a compiler general issue
or it was specific of our new cygwin64 platform
Invoking "undefined behaviour" on a test should be avoided. IMHO
Regards
Marco
···
Il 5/22/2013 6:43 PM, Sean McBride ha scritto:
On Wed, 22 May 2013 07:47:25 +0200, marco atzeri said:
testing 1.8.11 on the new cygwin64 platform with
Failures with the dt_arith test have been reported years ago, but it seems fixing it is not at the top of anyone's list.
The test invokes undefined behaviour, and modern optimizing compilers like gcc 4.8 are more and more performing optimizations assuming undefined behaviour does not occur.
On Wed, 22 May 2013 19:30:55 +0200, marco atzeri said:
Il 5/22/2013 6:43 PM, Sean McBride ha scritto:
On Wed, 22 May 2013 07:47:25 +0200, marco atzeri said:
testing 1.8.11 on the new cygwin64 platform with
Failures with the dt_arith test have been reported years ago, but it
seems fixing it is not at the top of anyone's list.
The test invokes undefined behaviour, and modern optimizing compilers
like gcc 4.8 are more and more performing optimizations assuming
undefined behaviour does not occur.
Cheers,
Thanks Sean ,
I saw on another package the gcc-4.8 optimization is producing wrong
output so I was just wondering if it was a compiler general issue
or it was specific of our new cygwin64 platform
Invoking "undefined behaviour" on a test should be avoided. IMHO
--
____________________________________________________________
Sean McBride, B. Eng sean@rogue-research.com
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
