Purpose:
Bug fix
Description:
Modification time test (mtime) would die silently on some systems. This is
because the code is very system-dependant (it relies on getting the current
time and the timezone from the OS).
Solution:
mtime test now uses TEST_ERROR macro to print "FAILED" and to output where the
failure occurred. Configure script is a little smarter about whether
gettimeofday() function returns the timezone correctly.
Further bugs will need to be addressed on a system-by-system basis.
Platforms tested:
sleipnir, arabica, verbena, copper, windows (VC7)
Code cleanup
Description:
Clean up collective chunking code a bit.
Also, add '--enable-instrument' configure flag to have a mechanism for
determining that optimized operations happened correctly in the library (instead
of just the "normal" way) by allowing 'flag' properties to be set outside the
library and set when the "right" thing happens. This is mainly for debugging
and regression checks, so we make certain we don't break optimized I/O by
accident. It's enabled by default when --enable-debug is on (which is on by
default in the development branch and off by default in the release branch),
but can also be independently controlled with its own configure flag.
Platforms tested:
FreeBSD 4.10 (sleipnir) w/parallel
IBM p690 (copper) w/parallel
Feature
Description:
Showed the fortran compiler and FFLAGS and CXX compiler and CXXFLAGS
when the corresponding language API is enabled.
Platforms tested:
No h5committest since it is just a simple shell script change.
Tested in Eirene.
Misc. update:
Purpose:
HDF5 now supports SZIP with no encoder.
Description:
SZIP can be configured to have both encoder and decoder or just to have the decoder. HDF5 can now query the configuration of any filter, and will throw errors if users try to write using a filter with encoding disabled.
Solution:
Added H5Zget_filter_info function, changed API for H5Pget_filter and H5P_get_filter_by_id. See SZIP RFC.
Platforms tested:
Copper (fortran, C++, parallel), Sleipnir (C++), Arabica (fortran, C++), Verbena (fortran, C++)
Misc. update:
Update shell scripts
Description:
Switch to generating the testh5dump.sh script at configure time, so we can
determine which filters are available to test.
Platforms tested:
FreeBSD 4.9 (sleipnir)
too small to require h5committest
Description: A new bug is found on HP. There is float exception during conversion from double to
unsigned long long when the value of double is very big.
Solution: Try to catch the problem in configure and skip this part of test.
Platforms tested: kelgia and verbena(mainly these two machines are involved)
Description: The HP compiler cannot convert from float-point numbers to unsigned long long
correctly. It sets the maximal value of unsigned long long as 0x7fffffffffffffff.
Solution: Skip the conversion test when this happens by testing it during configuration.
Platforms tested: kelgia(HP-UX 11) and fuss(RH 8)
Description: For certain compiler(PGI we know so far), during conversion
from float or double to unsigned long long, it does round-up when the
fraction part is greater than 0.5, which shouldn't happen.
Solution: check it during configuration and compensate this offset
during testing in dtypes.
Platforms tested: verbena and fuss. verbena is the only machine with
PGI compiler. Ran it on fuss to verify it with other compiler.
Description: Solaris 64-bit machines cannot handle round-up correctly during
conversion between unsigned (long) long and double.
Solution: During configuration, run a program to test if there is any failure
during conversion. Enable a macro if failures happen and adjust the test/dtypes
for round-up.
Platforms tested: h5committest, arabica 64-bit.
Bug fix (sorta)
Description:
Add hack to allow the MS Visual Studio 6 compiler to build the library.
It cannot cast unsigned long long values to float or double values. So, add
another configuration macro to disable this conversion in the library. Just
the "hardware" conversion is disabled, so the library will still correctly
convert unsigned long long to float and double values, it will just happen
more slowly with the "software" conversion routine.
Platforms tested:
FreeBSD 4.9 (sleipnir) with "Windows" setting faked
inappropriate for h5committest
Bug fix (sorta)
Description:
The SGI machines have problems accurately (and consistently) converting
unsigned long values to float and double values, so put in a bit of a hack in
the datatype conversion test code to allow them to get "close enough". This
hack is enabled at configure time by a flag which should only be set on machines
with this problem.
Platforms tested:
FreeBSD 4.9 (sleipnir)
h5committest
Bug fix
Description:
Add special-case handling to floating-point conversion tests to avoid
problems with denormalized values on Cray T3E & T90 platforms. (Still not
working on Cray SV1, but at least it's closer).
Solution:
Detect denormalized values and don't try to operate on them on the Crays.
Platforms tested:
FreeBSD 4.9 (sleipnir)
Cray T3E (hubble.cray.com)
Cray T90 (gypsy.cray.com)
Code cleanup, bug fixes
Description:
Wrap up rest of changes necessary for fixing the "short" MPI-I/O read
problem that Robb reported.
Platforms tested:
FreeBSD 4.9 (sleipnir)
too minor to require h5committest
Omnibus floating-point bug fix changes
Description:
There are a number of problems in the floating-point conversion code that
were exposed by Ray's recent int<->float checkin:
- The 'my_isnan' code in test/dtypes.c was broken and would always return
true. The meant that the actual values in the float<->float conversion
tests were _never_ checked, hiding the other bugs included in this
checkin.
- A recent change I made to the type conversion code used "FLT_MIN" instead
of "-FLT_MAX" for the most negative 'float' value for the double->float
conversion, which meant that any the negative number that was converted
from a double to a float would have been mapped to zero, essentially.
- A change that Robb appeared to have made ~2.5 years ago to the "generic"
float->float conversion routine appears to be incorrect and I've backed
it out.
- Floating-point conversions on SGI's which converted denormalized values
would be mapped to zero instead of being propertly preserved in the new
type. This was addressed by an SGI-specific system call to prevent the
behavior.
Solution:
Described above, generally.
Platforms tested:
FreeBSD 4.9 (sleipnir)
h5committest
Misc. update:
release_docs/RELEASE update forthcoming...
Bug fix & code cleanup
Description:
Allowing the library to call malloc with a size of 0 bytes causes problems
for some users, so we check for allocations of 0 bytes and disallow them now.
Cleaned up some code which could call malloc with 0 size.
Changed some code calling HDmalloc directly to call H5MM_malloc(), which
allows us to check for 0 sized allocations.
Platforms tested:
FreeBSD 4.9 (sleipnir)
too minor to require h5committest
More Checks
Description:
Added checks for correctly working "basename" and "xargs" programs.
Mike McKay was having troubles with the xargs. The basename check was
just a good idea.
Platforms tested:
Verbena, Arabica, Modi4
Misc. update:
updated help page
Description:
help message for enable-stream-vfd was still default=no.
changed to default=yes.
Platforms tested:
no h5committest. Only tested in eirene since change is
simple.
Misc. update:
Add check
Description:
Added a check to make sure that the "tr" program actually works.
Platforms tested:
Linux (small fix and only to configure)
Misc. update:
Update
Description:
Enable the stream-vfd driver by default. --disable-stream-vfd if you
don't want it.
Platforms tested:
Linux (configuration change, no need for full testing)
Misc. update:
