[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #YYM-734195]: 64 bit SunStudio cc/f90 netcfd 4.0

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: [netCDF #YYM-734195]: 64 bit SunStudio cc/f90 netcfd 4.0
  • Date: Wed, 28 Jan 2009 16:57:22 -0700
Hi,

I have duplicated the bug, but I don't have a satisfactory solution yet.

The bug seems to only occur when building ncdump with Sun compilers and -m64.
The
resulting ncdump doesn't even display the right value for a simple netCDF file
with one scalar variable of type double that has the value 4.  Instead it shows

  $ ncdump bug.nc
  netcdf bug {
  variables:
          double d ;
  data:

   d = 8.88178419700125e-16 ;
  }

although it works correctly with Sun compilers using -m32, with gcc compilers
on
Sun using either -m32 or -m64, and all other compilers we have tested on other
platforms with either -m32 or -m64.  In the dbx debugger, it appears that there
is nothing wrong with the ncdump code, it just calls the snprintf() function
from
ncdump/dumplib.c in the ncdouble_val_tostring() function and the Sun snprintf()
function returns the wrong value, from the line

        res = snprintf(sout, PRIM_LEN, varp->fmt, vv);

But the snprintf() function works fine in a small test program compiled with
-m64
and the Sun compiler.  Using gcc -m64 and the same snprintf() function from
Sun's
libc shared library also works fine.  All this points to a compiler bug, but
I'm
skeptical of that explanation.  I would need to isolate the problem to a
smaller
example than ncdump to convince myself or Sun that it's a compiler problem.

I've tried changes to compiler flags (no optimization) as well as changes to
the
code to work around the problem, but so far with no luck.  So this is just to
report that it may be necessary to use gcc on just one function to solve this.
I'll be trying that next ...

For now, I suggest you build a separate 32-bit installation and just install
the
ncdump utility from that manually, using that to finish the tests of your
64-bit
build.  The 32-bit ncdump utility can still read classic and 64-bit offset
netCDF files, so it has the same functionality.  I'll let you know if I come up
with a better solution ...

--Russ



Russ Rew                                         UCAR Unidata Program
address@hidden                     http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: YYM-734195
Department: Support netCDF
Priority: Normal
Status: Closed