| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Add version # and flags to external link format (as fields in a single
byte), in order to accomodate future changes/expansions.
Tested on:
Mac OS X/32 10.4.9 (amazon)
Linux/32 2.6 (chicago)
Linux/64 2.6 (chicago2)
FreeBSD/32 6.2 (duty)
FreeBSD/64 6.2 (liberty)
|
|
|
|
|
|
|
|
|
| |
copyright notice.
Tested platform:
Kagiso only since it is only a comment block change. If it works in one
machine, it should work in all, I hope. Still need to check the parallel
build on copper.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add "use the latest format" support for dataspace object header encode/
decode routines and clean up format a bit for the latest format (new to 1.8.x
releases)
Remove storing 'perm' parameter for array datatypes in memory and the file,
and add test to make certain that if any user applications are attempting to
store them, we get some reports back. (Should be unlikely, since the RefMan
says that the parameter is not implemented and is unsupported).
Carry those changes into the tests, etc.
Clean up a bunch more compiler warnings.
Tested on:
FreeBSD/32 4.11 (sleipnir) w/threadsafe
Linux/32 2.4 (heping) w/FORTRAN & C++
Linux/64 2.4 (mir) w/enable-1.6-compat
|
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Trim trailing whitespace in Makefile.am and C/C++ source files to make
diffing changes easier.
Platforms tested:
None necessary, whitespace only change
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: Mac OS 10.4 on PowerPC chip has some errors to convert (unsigned)
long long to long double. When the bit sequences are 0x003ff..., 0x007fff...,
0x00ffff..., 0x01ffff..., 0x7fffff..., the converted values are twice as big
as they should be.
Solution: Detect the error in configure and disable the compiler conversion
and test case.
Platforms tested: h5committest, Mac OS 10.4, and fuss.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
Description: Changed comment to better describe the code.
Platforms tested: No test is needed.
|
|
|
|
|
|
|
|
|
|
|
| |
Description: OpenVMS doesn't support denormalized floating-point values.
Disable the denormalized and special values for floating to floating-point
tests.
Platforms tested: OpenVMS - the only concerned machine.
Misc. update:
|
|
|
|
|
|
|
|
|
|
| |
Description: Two semicolons were missing in the code change for VAX support.
Solution: Fixed.
Platforms tested: fuss - too simple.
Misc. update:
|
|
|
|
|
|
|
| |
Description: changed macro VMS to H5_VMS
Platforms tested: no test needed
|
|
|
|
|
|
|
|
|
|
|
|
| |
Solution: Support VAX float and double types with new byte order. There're some
details not yet included,
1. the alignment detection for VAX order in H5detect.c.
2. support for special values in library conversion functions.
3. the infinity for VAX in H5T_init_inf.
4. support for VAX types in printing hexadecimal format.
Platforms tested: h5committest and fuss.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Check in some of the code cleanups from working on the external link
support. (This doesn't include any of the external link features)
Platforms tested:
FreeBSD 4.11 (sleipnir)
Mac OSX.4 (amazon)
Linux 2.4
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Fix a bunch of warnings flagged by Windows compilers.
Platforms tested:
FreeBSD 4.11 (sleipnir)
Too minor to require h5committest
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: H5T_register() replaces any existing data conversion path
with a new path.
Solution: Added a parameter to H5T_register() and H5T_path_find() to
signal the library whether the new conversion path is from API function
H5Tregister() or from private function like H5T_init_interface(). If it
is from H5Tregister(), replace existing path. If it's from H5T_init_interface()
and the library is trying to register default hard conversion functions,
don't replace existing path because the path is registered by the library.
For example, the library registered H5T_conv_int_float() and is trying to
register H5T_conv_long_float(). The size of long is equal to int. There's
no need to replace the path H5T_conv_int_float().
Platforms tested: h5committest and fuss.
|
|
|
|
|
|
|
|
|
|
|
| |
Description: The API function H5Tis_hard() which was recently checked
in has been renamed to H5Tcompiler_conv() to be more descriptive. No
other changes.
Platforms tested: fuss - simple change.
Misc. update: config/lt_vers.am to update libtool version.
|
|
|
|
|
|
|
|
|
|
| |
Description: Brought back changes from SX-6.
Solution: Tests will not compile. Fixed.
Platforms tested: SX-6, heping and mir with new g95
Misc. update:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: Quincey added the condition branch (else if (*((ST*)S) != (ST)((DT)(*((ST*)S)))))
in the definition of the macro H5T_CONV_Fx_CORE. It handles a special situation
when the source is "float" and assigned the value of "INT_MAX". Compilers do roundup
making this value "INT_MAX+1". This branch is to check that situation and return
exception for some compilers, mainly GCC.
The branch if (*((ST*)S) > (DT)(D_MAX) || (S_PREC < D_PREC && *((ST*)S) ==
(DT)(D_MAX))) is for some compilers like Sun, HP, IBM, and SGI where under
the same situation the "int" doesn't overflow.
A test was added to dt_arith.c to check 2 conversions, from float to int where the
float is INT_MAX, and from double to signed char where the double is SCHAR_MAX.
Platforms tested: h5committest and fuss.
|
|
|
|
|
|
|
|
|
| |
Description: Put in a new API funciton, H5Tis_hard. It checks whether
the conversion function from a native type to another native type is a
compiler (hard) conversion. Also checked a test in test/dt_arith.c.
Platforms tested: h5committest and fuss.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug fix & code cleanup
Description:
Address most of datatype conversion exception handling bug that Ed
Hartnett reported. (He's reported a different problem now, but we're closer
at least).
Also, condense exception handling #ifdef's into one location instead of
spread out in so many places.
Platforms tested:
FreeBSD 4.11 (sleipnir)
Too minor to require h5committest
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: Added 2 new configure options, --enable-exception and --enable-accuracy.
--enable-exception lets the library check whether user's exception handling
functions are present during compiler data conversions and use them if they are.
When it's disabled, this step is skipped to improve conversion speed. This
step isn't implemented yet for soft conversions because there would be little
gain in speed.
--enable-accuracy guarantees data accuracy during data conversions. It means
the library will choose compiler conversions only if the accurate data is
secured. Otherwise, the library will go for the library's own conversions. If
this option is disabled, the library uses compiler conversions in favor of
their speed as long as they work even if data can be incorrect.
Platforms tested: h5committest and fuss. Some systems may fail after this
checkin.
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Fix minor difference in datatype conversion exception callback routine.
Platforms tested:
FreeBSD 4.11 (sleipnir) w/C++
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code cleanup
Description:
Trim trailing whitespace, which is making 'diff'ing the two branches
difficult.
Solution:
Ran this script in each directory:
foreach f (*.[ch] *.cpp)
sed 's/[[:blank:]]*$//' $f > sed.out && mv sed.out $f
end
Platforms tested:
FreeBSD 4.11 (sleipnir)
Too minor to require h5committest
|
|
|
|
|
|
|
|
|
|
|
| |
New port
Description:
Elena asked me to check in her NEC SX-6 work, so here it is! :-)
Platforms tested:
FreeBSD 4.11 (sleipnir)
NEC SX-6 (by Elena)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: When converting floating-point numbers to integers and the values of
floating-point number are greater than the maximal value of integer, Cray X1 generates
floating exception.
Solution: Added a test in configure to detect Cray X1's exception. Set a flag to
indicate the machine that can handle overflow converting all floating-point to all
integer types. This flag should be set for all machines, except for Cray X1 where
floating exception is generated when the floating-point value is greater than the
maximal integer value.
Platforms tested: Cray X1 and h5committest.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Description: In this data conversion test, from floating number to floating number,
when the source is bigger than the destination, overflow may happen. The library
assign INFINITY while compiler's behavior is undefined. A compiler like SGI assigns
the maximal value for the destination.
Solution: When this situation occurs, simply check if the destination is INFINITY
instead of comparing values.
Platforms tested: modi4 and h5committest.
|
|
Description: Renamed test/dt_atomic.c to test/dt_arith.c(an abbreviation
of "arithmetic data types") to better describe the program. This checkin
broke down into three sections when the floating-point numbers are the
source, normalized, denormalized, and special values. If there's any
difference of destination values, only normalized value test reports
failure. The other 2 report only as warning.
Platforms tested: h5commitest and fuss
Misc. update: MANIFEST
|