[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Support #BPJ-806970]: netcdf-3.6.2 faild on ia64
- Subject: [Support #BPJ-806970]: netcdf-3.6.2 faild on ia64
- Date: Thu, 22 Mar 2007 16:34:30 -0600
Malte,
Thanks for sending the extra information, though it turns out it didn't help
diagnose the problem.
We have not seen this error before on any other platform, as far as I can
determine. It may be an indication of an error in our tests or a problem with
over-aggressive optimization by ifort. You might be able to determine if it is
an ifort problem by running the configure and "make check" again (after a "make
distclean") without the "-O2" optimization flag in CFLAGS and FFLAGS, that is
$ make distclean
$ ./configure CFLAGS=-g FFLAGS=-g ...
$ make check
If this works but using CFLAGS="-O2" doesn't work, that indicates a problem
with ifort that you can report to the compiler vendor. If it fails the same
way, then I'm not sure how to explain it.
What is hapening in more detail in the test that fails (ncsync and nf_sync) is
that a netCDF file is opened and written to, followed by a call to ncsync (but
not to ncclose()), so that the file is still open but presumably the writes
have been flushed to disk. Then it is reopened (so it is now open twice, with
two separate netCDF IDs), and read from the second ID. The values it gets
after the second open should agree with what was written, but they don't,
indicating that ncsysnc either didn't flush the user buffers to disk or the
second open didn't get the values from disk but perhaps from a cache somewhere
that didn't agree with the values that should have been flushed to disk.
I may be able to get access to a similar platfomr with ifort to see if we can
reproduce the problem here, but it will be a few days.
--Russ
Russ Rew UCAR Unidata Program
address@hidden http://www.unidata.ucar.edu
Ticket Details
===================
Ticket ID: BPJ-806970
Department: Support netCDF
Priority: Normal
Status: Closed