Re: [netcdfgroup] [EXTERNAL] Fortran compiler settings - ifort

  • To: Bart Brashers <bbrashers@xxxxxxxxxxx>
  • Subject: Re: [netcdfgroup] [EXTERNAL] Fortran compiler settings - ifort
  • From: Larry Baker <baker@xxxxxxxx>
  • Date: Mon, 19 Nov 2018 21:26:49 -0800
Bart,

I suspect the crash when you call nf_create() is caused by the 
-mixed-str-len-arg compiler option:

For string arguments with default ATTRIBUTES, ATTRIBUTES C, REFERENCE, or 
ATTRIBUTES STDCALL, REFERENCE:
When -nomixed-str-len-arg (Linux OS and Mac OS X) or /iface:nomixed_str_len_arg 
(Windows OS) is set, the length of the string is pushed (by value) on the stack 
after all of the other arguments. This is the default.
When -mixed-str-len-arg (Linux OS and Mac OS X) or /iface:mixed_str_len_arg 
(Windows OS) is set, the length of the string is pushed (by value) on the stack 
immediately after the address of the beginning of the string.

If the libraries are written in C, then they likely expect the default Fortran 
argument association.

As far as the program behavior when you remove -mixed-str-len-arg, it sounds 
like the program is invalid.  When you say the program crashes, are you not 
getting Intel messages and tracebacks when the array indexes are out-of-bounds? 
 I hope so, because they will tell you which array is being improperly accessed 
and where.  I recommend compiling and running with as much error checking as 
possible, such as the improper use of uninitialized variables.  -extend-source 
usually means the source code is fixed-format and spills past column 72.  That 
can often lead to truncated variable names that are still legal, but not what 
the programmer intended.  Uninitialized or mis-typed variables can result, 
especially if the code does not use Implicit None.

I am not a NetCDF user.  What you have described sounds like behavior that is 
not related to NetCDF, but improper argument association and program bugs.

Regards,

Larry Baker
US Geological Survey
650-329-5608
baker@xxxxxxxx




> On Nov 19, 2018, at 7:00 PM, Bart Brashers <bbrashers@xxxxxxxxxxx> wrote:
> 
> Hi all,
>  
> I have a code compiled with ifort, the intel Fortran compiler. The flags it 
> uses look like this, though -traceback is probably temporary for debugging:
>  
> FCFLAGS = -c -names lowercase -O2 -fp-model strict -fpic -assume byterecl 
> -mixed-str-len-arg -align sequence -traceback
>  
> I’ve compiled zlib-1.2.8, hdf5-1.8.11, and netcdf-4.1.2* using these FCLAGS 
> (FFLAGS).
>  
> When I run my compiled code I get a Segmentation Fault immediately as the 
> code calls nf_create(). That’s not a particularly complicated subroutine, so 
> I’m puzzled.
>  
> If instead I use extremely minimal flags for zlib, hdf5, and netcdf:
>  
> FFLAGS = -g
>  
> and these flags for the main code:
>  
> FCFLAGS = -c -g -traceback -check bounds -align dcommons -extend_source 
> -static_intel
>  
> Then I can compile and run the code, and create a netCDF file using 
> nf_create(), and add attributes, variables, etc. But the main code behaves 
> erratically and crashes for other reasons that seem mostly related to 
> indexing of arrays.
>  
> Can someone suggest either a “standard” set of FCFLAGS I should be using for 
> zlib, hdf5, and netcdf; or a sub-set of the flags above for the main code 
> that might work with netCDF? The main hint is the immediate SegFault after 
> calling nf_create(). CFLAGS in both cases is simple, just “-g”. Extra hint: 
> using pgfortran for everything works just fine.
>  
> Platform: CentOS 7.4
> ifort is the latest (2019) using a trial license. 
>  
> * I’m very aware that I should be using a newer version of the netcdf libs, 
> but this version is being used by the code authors. I suspect they like the 
> unified C and Fortran compilation.
>  
> Bart
> _______________________________________________
> NOTE: All exchanges posted to Unidata maintained email lists are
> recorded in the Unidata inquiry tracking system and made publicly
> available through the web.  Users who post to any of the lists we
> maintain are reminded to remove any personal information that they
> do not want to be made public.
> 
> 
> netcdfgroup mailing list
> netcdfgroup@xxxxxxxxxxxxxxxx <mailto:netcdfgroup@xxxxxxxxxxxxxxxx>
> For list information or to unsubscribe,  visit: 
> http://www.unidata.ucar.edu/mailing_lists/ 
> <http://www.unidata.ucar.edu/mailing_lists/>
  • 2018 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the netcdfgroup archives: