Due to the security enhancements in Mac OS 10.11 El Capitan, I am being forced to discontinue using the DYLD_LIBRARY_PATH environment variable to find dynamic libraries, and to use install_name_tool instead, as described in the Intel Developer article Application Configuration for Dynamic Libraries - however I am finding that doing so breaks the Intel code signature, which in turn disables the display of symbols in Xcode Instruments. Xcode also crashes randomly when debugging code that loads libraries modified in that way.

First, I can verify that a library such as lib/libifcore.dylib is signed by Intel:

% codesign --verify --verbose lib/libifcore.dylib
lib/libifcore.dylib: valid on disk
lib/libifcore.dylib: satisfies its Designated Requirement

Then I use install_name_tool to specify that the library itself, as well as the other Intel Fortran dynamic libraries it needs, can be found in one of the run path directories I specify for my executable:

% install_name_tool -id @rpath/libifcore.dylib lib/libifcore.dylib
% install_name_tool -change libifcore.dylib @rpath/libifcore.dylib lib/libifcore.dylib
% install_name_tool -change libimf.dylib @rpath/libimf.dylib lib/libifcore.dylib
% install_name_tool -change libintlc.dylib @rpath/libintlc.dylib lib/libifcore.dylib
% install_name_tool -change libsvml.dylib @rpath/libsvml.dylib lib/libifcore.dylib

However, at this point the code signature is now invalid:

% codesign --verify --verbose lib/libifcore.dylib
lib/libifcore.dylib: invalid signature (code or signature have been modified)
In architecture: x86_64

This has recently become a problem not just from a code security standpoint in general, but because Xcode Instruments is now apparently checking code signatures, and an invalid signature in any dynamic library used by my executable completely disables the display of any symbols in Instruments, and is also causing crashes in the Xcode debugger. I fear that Apple may decide at some point not to allow such executables to run at all. I feel that for maximum flexibility, Intel should be shipping code-signed Intel Fortran libraries that already use '@rpath' to specify where they can be found, either instead of, or in addition to, the ones that are currently shipping. I see that this is already being done for other Intel Products such as in this recent release of the OpenMP Runtime Library - how soon could we see a similar change to Intel Fortran?

Hi all,

I asked this question on "Code Modernization" forum, but I did not received any answer hence I created a new thread here on this forum.

The first question:

I found medium size ~10K loc of  FORTRAN 77 source code which describes  complete computational flight dynamics simulation. I would like to convert this code which exists only in printed form to C++ version in order to use it in my missile simulation open source project.

 After browsing through the sources I realized that, subroutines pass information between themselves with the help of COMMON blocks only.  I would like to ask you what will be the best approach for the code conversion?  My biggest problem is related to massive usage of COMMON blocks which will imply usage of dedicated namespace to host those global variables extracted from the COMMON blocks. The other option more secure is to put all global variables from the common block to anonymous namespace which is visible only from the single translation unit, but this approach will force me to write all classes in single file.

The second question:

This question is related to code conversion from FORTRAN 90 repository to C++.

I am thinking about 3 approaches:

1) Translation of FORTRAN 90 module to single C++ translation unit in its own namespace with FORTRAN subroutines converted to C++ global(namespace functions) and module globals which can be represented as a members of anonymous namespace.

2) Trying to create simple OOP design by for example converting FORTRAN subroutine into simple C++ class where subroutine's output argument(s)  can be represented as class member variable(s). One of the problem will be a large number of  some subroutine's arguments passed to it, additional problem will be issue of global variables representation in C++, but I think this can be handled by using named namespace solely dedicated to globals.

3) Use translation tool like f2c and manually convert from C version to C++, which btw I already did while porting NRLMSISE_00 atmosphere model to C++.

Thank you in advance.

Hi all,

I'm running a pretty heavy MPI application (the WRF model) on Linux and get a BUS error (please see below the output for the type of the error) --- any idea how to isolate the cause (specific line of bad coding), or system/compiler/MPI related issue ?

Have you guys had an experience of catching these bugs with one of Intel's new tools ?

Thanks in advance for your perspective and experience,

Jack.

###

rsl.error.0010:[n13:mpi_rank_10][error_sighandler] Caught error: Bus error (signal 7)

Hi,

I tried to install an old version of Intel suite: "Intel fortran compiler 11.1", but it reports some issues about kernel, glibc and binutils version. After that procedure just fails.

System glibc or kernel version not supported or not detectable.
Supported glibc/kernel versions:
architecture    kernel        glibc
IA-32          2.4           2.2.93, 2.3.2
IA-32          2.6           2.3, 2.4, 2.5, 2.6

And the following:

Binutils version not supported or not detectable.
Supported versions are greater than 2.13.

On the other hand on my system I have the following versions:

Arch: IA_32
Kernel: 3.19.4
glibc: 2.15
binutils: 2.22.52.0.2

Now I'd ask which version of "Intel suites" (containing ifort compiler) could be compatible with my system?

Eg.

Would "Parallel Studio XE 2016" work on my system? Or should I need an older Intel product? which one for example?

Thanks in advance,

Regards.

Hi, 

I'm compiling an ice sheet model using IFORT. If I add or remove some very simple write-type code, I have the following error message 

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
libintlc.so.5      00007F4D9B0E3961  Unknown               Unknown  Unknown
libintlc.so.5      00007F4D9B0E20B7  Unknown               Unknown  Unknown
libifcore.so.5     00007F4D9CAA41D2  Unknown               Unknown  Unknown
libifcore.so.5     00007F4D9CAA4026  Unknown               Unknown  Unknown
libifcore.so.5     00007F4D9CA10E0C  Unknown               Unknown  Unknown
libifcore.so.5     00007F4D9CA21BF8  Unknown               Unknown  Unknown
libpthread.so.0    00007F4D9AEC9340  Unknown               Unknown  Unknown
sheetshelf.exe     000000000AA54D90  Unknown               Unknown  Unknown

Here is an example  of a write command I removed 

#       do iu = ioterm, iuout1d, iuout1d-ioterm
#       write (iu,'(a,i3,2(a,f10.4))')
#     *    'itera=',itera, ' delmaxa=',delmaxa,' delcrita=',delcrita
#       enddo

and here is an example of a write command I added 

#       write(*,*)'crhu-schoof',crhu(iau,j),iau,j

I checked many times that there are no errors re the variables I want to be written, so I really can't understand why this happens. Do you have any hint how to understand more of this error? 

Thank you,

Michele

Hi,

Is the 2013 SP1 version of Intel Fortran Compiler still available? If it is there, where to download it from? The software we are using is compatible with this particular version of Intel Fortran Compiler only so any information regarding the existence of this version will be helpful.

Regards,

Abir S

I wanted to recompile one code(have worked with this f90 program two years ago).My makefile

F95ROOT=/home/milenko/intel/compilers_and_libraries/linux
MKLROOT=/home/milenko/intel/compilers_and_libraries/linux/mkl

FC90 = $(F95ROOT)/bin/compilervars.sh intel64 linux
FCFLAGS= -O2 -fast -warn uncalled

INCLUDE = $(MKLROOT)/include
LD_LIBRARY_PATH = $(MKLROOT)/lib/intel64
LIBRARY_PATH = $(MKLROOT)/lib/intel64
CPATH = $(MKLROOT)/include
FPATH = $(MKLROOT)/include
NLSPATH = $(MKLROOT)/lib/intel64/locale/en_US
LIBS=-L$(MKLROOT)/lib/intel64 -lmkl_lapack95 -Wl,--start-group \
$(MKLROOT)/lib/intel64/libmkl_lapack95.a \
$(MKLROOT)/lib/intel64/libmkl_blacs.a -Wl,--end group

TARGETS= clean Occam2D

OBJSOC= OccamModules.f90 MT2DModules.f90 Occam.f90 MT2D.f90

all: $(TARGETS)

clean:
        rm -f *.o *~ core *.mod
        rm -f Occam2D
        
Occam2D:$(OBJSOC)
        $(FC90) $(FCFLAGS) -o $@ $(OBJSOC)  $(LIBS)

# General compile rules

.SUFFIXES: .f90 .o

.f90.o:    
    $(FC90) $(FCFLAGS)    -c -o $@ $< 

But when I try to compile it I got

milenko@milenko-HP-Compaq-6830s:~/OCCAM2DMT_V3.0/cifort$ make all
rm -f *.o *~ core *.mod
rm -f Occam2D
/home/milenko/intel/compilers_and_libraries/linux/bin/compilervars.sh intel64 linux -O2 -fast -warn uncalled -o Occam2D OccamModules.f90 MT2DModules.f90 Occam.f90 MT2D.f90  -L/home/milenko/intel/compilers_and_libraries/linux/mkl/lib/intel64 -lmkl_lapack95 -Wl,--start-group /home/milenko/intel/compilers_and_libraries/linux/mkl/lib/intel64/libmkl_lapack95.a /home/milenko/intel/compilers_and_libraries/linux/mkl/lib/intel64/libmkl_blacs.a -Wl,--end group
compilervars.sh [-arch] <arch> [-platform <platform>]

  <arch> must be one of the following:
      ia32           : Set up for IA-32 target.
      intel64        : Set up for Intel(R)64 target.
  <platform> must be of the following:
      linux          : Set to Linux target.(default)
      android        : Set to Android target.

If the arguments to the sourced script are ignored (consult docs
for your shell) the alternative way to specify target is environment
variables COMPILERVARS_ARCHITECTURE to pass <arch> to the script
and COMPILERVARS_PLATFORM to pass <platform>
make: *** [Occam2D] Error 1

I do not understand,how to set up arch and platform?

I could compile and run a code on linux clusters without a problem. Now I want to run the same code on a brand new iMac, but I receive segmentation error when I run the same code. On linux I had to use the following flag:

FC=ifort
FFLAGS= -mcmodel medium -shared-intel

but because -mcmodel is not supported, I have to comment it out. Can this be the reason of this problem?Is there any alternative for MACs?

I have tried the following flags and non of them works:

FFLAGS= -heap-arrays

or

FFLAGS= -heap-arrays 10

or

FFLAGS= -Wl,-stack_size -Wl,10000000

PS: I just bought the iMac and I've installed the last version of intel fortran parallel studio. 

Hi,

trying to avoid a compilation cascade, I have been looking at how Intel Fortran generates .mod files. Searching in the internet, I thought that Intel Fortran would include a timestamp in the first few bytes of the .mod file, so that if I ignored those first bytes I could see whether the .mod definitions actually changed from one compilation to another. But this is not working as expected. For one of the files in our code I do:

[angelv@duna]$ h5pfc -O0 -fpp  -c mancha_src/globals.F90
[angelv@duna]$ cp globals.mod globals.mod.backup
[angelv@duna]$ h5pfc -O0 -fpp  -c mancha_src/globals.F90
[angelv@duna]$ cmp -l globals.mod globals.mod.backup
   49 126 115
18684 122 337
[angelv@duna]$ h5pfc --version
ifort (IFORT) 15.0.2 20150121
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

[angelv@duna]$

So, those two .mod files, generated without modifying the source file at all differ in the byte 49 (OK, as expected due to the timestamp), but also in the byte 18684 (this is about 30% into the file).

Is there any way to avoid these changes in the .mod files except in some fixed position in the file?

As another example, for the json_module.F90 file (available from http://jacobwilliams.github.io/json-fortran/sourcefile/json_module.f90.html), I get even more differences:

[angelv@duna]$ ifort -O0 -fpp  -c mancha_src/json_module.F90
[angelv@duna]$ cp json_module.mod json_module.mod.backup
[angelv@duna]$ ifort -O0 -fpp  -c mancha_src/json_module.F90
[angelv@duna]$ cmp -l json_module.mod json_module.mod.backup
   49 224 217
28156 165 140
28364 165 140
28572 165 140
28780 165 140
28988 165 140
29548 165 140
29713 165 140
30626 165 140
[angelv@duna]$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.2.164 Build 20150121
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

[angelv@duna]$

Thanks,

Ángel de Vicente

Is

We have followed the same procedure that was working for previous versions of the compiler and installed to our on premise file server.  We have recently acquired via Intel a serial number for the cluster edition which we have installed to the fileserver using the provided licence file.

When we test the install, we see the error shown below,

(test_intel_compilers): checking using environment from /fserver/intel/opt/intel/compilers_and_libraries/linux/bin/compilervars.sh.
(test_intel_compilers): checking ia32.
(test_intel_compilers): checking ifort.
(test_intel_compilers): which ifort: /fserver/intel/opt/intel/compilers_and_libraries_2016.2.181/linux/bin/ia32/ifort.
(test_intel_compilers): version output begins.

Error: A license for Comp-FL is not available now (-97,121).A connection to the license server could not be made.  You should
make sure that your license daemon process is running: both an
lmgrd process and an INTEL process should be running
if your license limits you to a specified number of licenses in use
at a time.

Is the new serial number a floating licence requiring a licence server?

The serial number is [deleted[

Regards,

Paul

I could compile and run a code on linux clusters without a problem. Now I want to run the same code on a brand new iMac, but I receive segmentation error when I run the same code. On linux I had to use the following flag:

FC=ifort
FFLAGS= -mcmodel medium -shared-intel

but because -mcmodel is not supported, I have to comment it out. Can this be the reason of this problem?Is there any alternative for MACs?

I have tried the following flags and non of them works:

FFLAGS= -heap-arrays

or

FFLAGS= -heap-arrays 10

or

FFLAGS= -Wl,-stack_size -Wl,10000000

PS: I just bought the iMac and I've installed the last version of intel fortran parallel studio. 

Hi,

The Intel Fortran compiler on Mac, is giving me the error message:

 Illegal instruction: 4

What does this mean? And what can I do about it?

I think it is due to a compile option I am using with the Intel Fortran compiler, however I have no idea which flag is causing this.

Thanks,

Andy

Hi,

the following code will yield a catastrophic error when compiled using 16.0.2

module whimpfort
  private
  ! Make a circle

  integer, parameter :: N=128
  real, parameter :: pi=3.14
  real, parameter :: tooclose=0.5
  real, parameter :: R=tooclose
  real, parameter :: bigR=3*R
  integer :: ii
  complex, parameter :: circ_points(N) = [ (R*exp((0.,1.)*2.*pi*(ii-1)/real(N)),ii=1,N) ]
end module whimpfort

The line responsible for the crash is the one defining the `circ_points array' via the array constructor.

You guys should use my code for testing ;)

EDIT: I tried it with ifort 12--15 version and they all have problem with this. GNU compiler, gfortran ver 5, does what I want.

I am developing a C# extension dll in VS 2010, using fortran dll having Intel fortran compiler. this fortran dll code does uses IMSL DIVPAG solvers in code. when i am using COMPAQ compiler based fortran dll which also uses DIVPAG solvers from IMSL library, in C# extension development, facing some issue, where my c# code does not get connected to this fortran dll or getting crashed. How fortran compiler is making an issue, where i am only using dll in C#. How to solve this issue please tell me. Thanks in advance.

Dear Intel Fortran developers, 

I'm using ifort 15.0.1 in my code. I have a problem with array alignment. This is a piece of my code in a subroutine

real(stnd), dimension(:), allocatable :: dsr_sel
!DIR$ ATTRIBUTES ALIGN: 32 :: dsr_sel


allocate(dsr_sel(ntracesM))

s = 1
e = ntracesM

dsr_sel(s:e) =  off_co(s:e)*off_co(s:e)*inv_off2 +  &
                       (  x_co(s:e)-x0cur )*( x_co(s:e)-x0cur )*inv_ap2

where x_co and off_co are array defined in a module and allocated in another point by using !DIR$ ATTRIBUTES ALIGN : 32 :: x_co, off_co. The problem is opt report file give me: 

LOOP BEGIN at project/src/test.f90(646,8)<Peeled>
LOOP END

LOOP BEGIN at project/src/test.f90(646,8)
   remark #15389: vectorization support: reference DSR_SEL has unaligned access
   remark #15389: vectorization support: reference test_mp_off_co_ has unaligned access
   remark #15389: vectorization support: reference test_mp_off_co_ has unaligned access
   remark #15389: vectorization support: reference test_mp_x_co_ has unaligned access
   remark #15389: vectorization support: reference test_mp_x_co_ has unaligned access
   remark #15381: vectorization support: unaligned access used inside loop body
   remark #15399: vectorization support: unroll factor set to 2
   remark #15300: LOOP WAS VECTORIZED
   remark #15442: entire loop may be executed in remainder
   remark #15450: unmasked unaligned unit stride loads: 2
   remark #15451: unmasked unaligned unit stride stores: 1
   remark #15475: --- begin vector loop cost summary ---
   remark #15476: scalar loop cost: 20
   remark #15477: vector loop cost: 5.000
   remark #15478: estimated potential speedup: 6.120
   remark #15479: lightweight vector operations: 17
   remark #15488: --- end vector loop cost summary ---
LOOP END

LOOP BEGIN at project/src/test.f90(646,8)
<Remainder>
   remark #15389: vectorization support: reference DSR_SEL has unaligned access
   remark #15389: vectorization support: reference test_mp_off_co_ has unaligned access
   remark #15389: vectorization support: reference test_mp_off_co_ has unaligned access
   remark #15389: vectorization support: reference test_mp_x_co_ has unaligned access
   remark #15389: vectorization support: reference test_mp_x_co_ has unaligned access
   remark #15381: vectorization support: unaligned access used inside loop body
   remark #15301: REMAINDER LOOP WAS VECTORIZED
LOOP END

I don't understand why these tree vectors have unaligned accesses. I compile with -xHost and -O3 flags on Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz. I tried also -align array32byte with no results. 

Thanks.

All,

I'm currently trying to port a code that works on Intel 15 to use Intel 16 (and 17). In doing so, I encountered a difference in behavior of Intel 16 and 17 compared to 15 (as well as to NAG, PGI, and GNU). A variant also showed a possible bug in Intel 15.

The code is:

program test

   implicit none

   integer, parameter :: nvars = 12
   character(len=*), parameter :: vars(nvars)=(/ &' dw', ' ps', ' pw', ' rw',  &'  q', 'spd', '  t', ' uv',  &'sst', 'gps', 'lag', 'tcp' /)
   integer :: ivars(nvars)
   logical :: lvars(nvars)
   integer :: i
   character(len=3) :: var
   integer :: is(1)

   integer :: iis

   is = 0
   iis = 0

   do i=1,nvars
      ivars(i) = i
   end do

   var = 'X'

   write (*,*) 'var: ', var
   write (*,*) 'vars: ', vars
   write (*,*) 'ivars: ', ivars
   write (*,*) 'vars==var: ', vars==var

   is = maxloc(ivars,vars==var)
   write (*,*) 'is: ', is

   lvars = vars==var
   write (*,*) 'lvars: ', lvars

   iis = maxloc(ivars,dim=1,mask=lvars)
   write (*,*) 'iis: ', iis

end program test

What we are trying to do is find where "var" is in "vars". Now, is maxloc the way to do this? No, probably not, but, still, before I workaround, I want to report this. In this case, since 'X' is not in vars, is -> 0. I've also added a new chunk of code using MAXLOC(ARRAY,DIM=DIM,MASK=MASK) thinking maybe that would help.

Now in Intel 15:

(1513) $ ifort --version
ifort (IFORT) 15.0.2 20150121
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

(1514) $ ifort test.F90 && ./a.out
 var: X
 vars:  dw ps pw rw  qspd  t uvsstgpslagtcp
 ivars:            1           2           3           4           5           6
           7           8           9          10          11          12
 vars==var:  F F F F F F F F F F F F
 is:            0
 lvars:  F F F F F F F F F F F F
 iis:            1

Note, is=0 which is why the larger code this is part of worked. My 'dimmed' attempt to see if using dim=1 and outputting an integer threw a 1, which is unexpected.

Now Intel 16:

(1362) $ ifort --version
ifort (IFORT) 16.0.2 20160204
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

(1363) $ ifort test.F90 && ./a.out
 var: X
 vars:  dw ps pw rw  qspd  t uvsstgpslagtcp
 ivars:            1           2           3           4           5           6
           7           8           9          10          11          12
 vars==var:  F F F F F F F F F F F F
 is:            1
 lvars:  F F F F F F F F F F F F
 iis:            1

Now is=1. My reading of the standard seems that this use of MAXLOC falls under Case (ii) of the MAXLOC spec:

...If ARRAY has size zero or every element of MASK has the value false, all elements of the result are zero.

Every element of MASK is false is both MAXLOC calls so I think the result should be 0.

Thanks,

Matt

Hi,

I'm trying to use -check uninit to find uninitialized variables in my code:

+ mpif90 -I/usr/local/other/SLES11.3/ncl/gcc-4.3.4/6.3.0-static/include -I/usr/local/other/SLES11.3/silo/4.10.2/include -extend-source -r8 -c -O2 -g -traceback -check uninit -warn noalign 3dpic_full_mpi.f
+ mpif90 -o 3dpic_full_mpi.exe 3dpic_full_mpi.o -L/usr/local/other/SLES11.3/ncl/gcc-4.3.4/6.3.0-static/lib -L/usr/local/other/SLES11.3/silo/4.10.2/lib -lsiloh5 -lhdf5_hl -lhdf5 -lsz -lz -lm -lrt -ldl -lstdc++ -O2 -g -traceback -check uninit -mcmodel medium

But it doesn't work.

Can you tell me what should I do?

Thanks

GB

I am using Intel Fortran compiler (ifort version 16.0.2) and I want to compile a (monte carlo) code which has the option -i-static in the make file, but I got the error message "ifort: command line remark #10148: option '-i-static' not supported" though the code was used by other colleague earlier without problem (using version 14). Can the version difference cause the problem, if yes what is the proper substitution for the option? or is there some other setting which might be not properly set on my PC? thanks!

Consider the following example code. I want to call a C function that is returning a char* (in the example, this is dlerror). What I have here seems to work OK. I'm wondering about memory leaks though. In the c_to_fortran_string function (which is based on something I found on the internet), there is some C_F_POINTER voodoo to get the result into a Fortran deferred length string. Is this the best way to do this? Do I need to worry about memory leaks here? I notice that I can deallocate STRING_ARRAY, but if I try to deallocate STRING, I get a "double free or corruption" error. Not sure what that means or if it's something I need to worry about. Any help is appreciated!

program load_library_test

  use, intrinsic :: iso_c_binding

  implicit none

  character(len=*),parameter :: dll_name = 'blah.so'
  integer(c_int),parameter :: rtld_lazy  = 1

  integer(c_intptr_t) :: ihandle
  character(len=:),allocatable :: error_message

  interface
    function dlopen(library, iflag) result(handle) bind(C, name='dlopen')
      import
      implicit none
      integer(c_intptr_t) :: handle
      character(kind=c_char),intent(in),dimension(*) :: library
      integer(kind=c_int),intent(in),value :: iflag
    end function dlopen
    function dlerror() result(error) bind(C, name='dlerror')
      import
      type(c_ptr) :: error
    end function dlerror
  end interface

  ihandle = dlopen(trim(dll_name)//c_null_char, rtld_lazy)

  if (ihandle == 0) then
    error_message = GetError()
    write(*,'(A)') error_message
  else
    write(*,'(A)') 'Success!'
  end if

  contains

  function GetError() result(error_message)

    implicit none

    character(len=:),allocatable :: error_message

    type(C_PTR) :: p

    if (C_ASSOCIATED(p)) then
      error_message = 'UNKNOWN ERROR'
    else
      error_message = c_to_fortran_string(dlerror())
    end if

  end function GetError

  function c_to_fortran_string(cstr) result(str)

    implicit none

    type(c_ptr),value  :: cstr
    character(len=:),allocatable :: str

    character(c_char),dimension(:),pointer :: string_array
    character(kind=c_char,len=1),pointer :: string
    integer :: i ! counter

    str = '' ! initialize

    if (c_associated(cstr)) then
      call c_f_pointer(cptr=cstr, fptr=string)
      call c_f_pointer(cptr=cstr, fptr=string_array, shape=[c_string_length(string)])
      do i=1,size(string_array)
        str = str // string_array(i)
      end do
      if (associated(string_array)) deallocate(string_array)  !this works
      !if (associated(string)) deallocate(string)  ! crashes... "double free or corruption (fasttop)"
    end if

  end function c_to_fortran_string

  function c_string_length(string) result(length)

    implicit none

    character(c_char),dimension(*),intent(in) :: string
    integer :: length

    length = 0
    do while(string(length+1)/=c_null_char)
      length = length + 1
    end do

  end function c_string_length

end program load_library_test

  We recently updated the NFS servers on our HPC cluster (Scientific Linux 6.7) to use NFSv4 from v3. Some programs compiled with ifort (16.0.2, 11.0, probably others) failed to open files on an NFSv4 filesystem mounted read only. The ifort run-time error was 43 (A pathname or file name given to an OPEN or INQUIRE statement was not acceptable to the Intel® Fortran RTL I/O system.). The file could be read by the same program compiled with gfortran 5.3.0.

  The fortran line was:

open (unit=iunit, file=filename(1:lfil), form='formatted', iostat=ios)

  The relevant strace output for ifort-compiled:

open("/path/to/file", O_RDWR|O_CREAT, 0666) = -1 EROFS (Read-only file system)
open("/path/to/file", O_RDONLY|O_CREAT, 0666) = -1 ENOTDIR (Not a directory)

and gfortran:

open("/path/to/file", O_RDWR|O_CREAT|O_CLOEXEC, 0666) = -1 EROFS (Read-only file system)
open("/path/to/file", O_RDONLY|O_CLOEXEC) = 3

  Since "status" and "action" are unspecified in the fortran open(), the compiler is left to decide what is best. They both first try to open the file read-write, creating it if non-existent. When this fails due to being a read-only file system, ifort tries "open read-only, or create", while gfortran doesn't attempt the create. From what I can tell, the O_RDONLY|O_CREAT combination is POSIXly legal, but is not being handled well by the NFSv4 parts of kernel  2.6.32-573.18.1.el6.x86_64. 

  A quick work-around is to set status='old' and/or action='read' in the fortran open(). The first will not try to open with O_CREAT, while the second succeeds immediately with O_RDONLY.

  Does the O_RDONLY|O_CREAT combination ever make sense? Should ifort-compiled programs simply skip the O_CREAT flag when falling back from an EROFS? What's the best way to report this to the ifort and NFS maintainers?

[Edit: Submitted as bug to RH: https://bugzilla.redhat.com/show_bug.cgi?id=1329769]

Thanks,

Nate Crawford