|
Description
|
FULL PRODUCT VERSION :
Sun C 5.10 SunOS_i386 2009/06/03
ADDITIONAL OS VERSION INFORMATION :
SunOS cs1 5.10 Generic_138889- customer i86pc i386 i86pc
A DESCRIPTION OF THE PROBLEM :
Building the NetCDF package (http://www.unidata.ucar.edu/software/netcdf/) with Sun Studio on x86 for 64bits and with optimizations turned on results in a broken ncdump executable. It extracts wrong number values from the NetCDF data files, which is rather fatal for a library for storing and retrieving said numerical values.
The NetCDF project has a long-established codebase that is used in scientific computing around the world on various platforms and using various compilers. It also happens to be compiled fine with Sun Studio on x86 in 32bit mode, as well as Sun Studio on SPARC (though did not use 64bit mode there).
There may be a bug in the NetCDF sources, but it seems far more likely that this is an issue with the optimizations done by the Sun compiler, its port to x86-64 being rather young, even.
For further description of the problem as well as an additional test case please refer to those discussions on the NetCDF mailing list:
http://www.unidata.ucar.edu/support/help/MailArchives/netcdf/msg05358.html
http://www.unidata.ucar.edu/mailing_lists/archives/netcdfgroup/2009/msg00230.html
as well as the extracted "known problems" entry:
http://www.unidata.ucar.edu/software/netcdf/docs/known_problems.html
Also, the user first experiencing this reported the following in private communication:
here's the solution with the Sun compiler:
ncdump/dumplib.c must be compiled using -O0 explicitly, otherwise
-O2 is used by default. By hand, just remove dumplib.o, add -O0
to CFLAGS in the Makefile (second occurence), and gmake . The
depending programs are recompiled and the tests succeed.
This seems to be an optimizer bug, I've checked the code produced,
and it does not set the xmm0 register in the complicated
version and breaks calling ABI for libc, whereas your simple code
below shows that it is set as expected. The value printed is just
a random value in xmm0 used for something before. I've just halted the code
before entering snprintf and set xmm0 explicitly to the value, continued,
and, voila, the value printed is correct !
The instructions generated are TOTALLY different, a symptom I've seen
very often, just adding a line somewhere completely changes the
generated code, which makes it really hard to track down such errors.
I'll report this to Sun, maybe they've a better clue why this happens.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Download NetCDF source on a Solaris x86 system:
http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz
In the extracted source directory (bourne shell):
sh$ CFLAGS='-m64' CC=/opt/studio12.1/bin/cc ./configure --disable-cxx --disable-f77 --disable-f90
sh$ make
sh$ make check
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Successful run of all tests. No FAIL messages.
ACTUAL -
Please refer to the mailing list archive links for a specific test case for ncdump (those included in NetCDF do not cover all possible failures, apparently).
*** Testing ncgen and ncdump using some test CDL files.
*** creating tst_small.nc from ref_tst_small.cdl...
*** creating tst_small.cdl from tst_small.nc...
*** creating test0.nc from test0.cdl...
*** creating test1.cdl from test0.nc...
*** creating test1.nc from test1.cdl...
*** creating test2.cdl from test1.nc...
*** checking that test1.cdl and test2.cdl are the same...
62,63c62,63
< 8.88178419700125e-16, 1.11022302462516e-15, 1.33226762955019e-15,
< 1.55431223447522e-15, 1.77635683940025e-15, 222044604925031 ;
---
> 1.97215226305253e-31, 2.46519032881567e-31, 2.9582283945788e-31,
> 3.45126646034193e-31, 3.94430452610506e-31, 0.0493038065763132 ;
FAIL: run_tests.sh
*** Testing ncgen and ncdump with 64-bit offset format.
*** creating test0.nc from test0.cdl...
*** creating test1.cdl from test0.nc...
*** creating test1.nc from test1.cdl...
*** creating test2.cdl from test1.nc...
test1.cdl test2.cdl differ: char 896, line 62
FAIL: tst_64bit.sh
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
http://www.unidata.ucar.edu/downloads/netcdf/ftp/netcdf-4.0.1.tar.gz
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Build the whole ncdump subdirectory (or all of NetCDF) with "-m64 -O0", or everything with -m32 instead.
Posted Date : 2009-07-27 21:43:36.0
|
|
Comments
|
Submitted On 10-AUG-2009
I vote to fix this bug.
Submitted On 10-AUG-2009
Fixing this bug will serve the large netCDF community, many of who depend on Sun compilers.
Submitted On 12-AUG-2009
Fixing this bug would serve not only the netCDF community, but also the larger communities that depend on the netCDF libraries (e.g., WRF).
Submitted On 26-AUG-2009
Naaasty bug! All my works rely on netcdf, and I have lot of collegues using SunOS with Sun developer tools. Please FIX.
PLEASE NOTE: JDK6 is formerly known as Project Mustang
|