Hi,

some DO-loops in my code are slower when the code is compiled with -xAVX (and -align array32byte). Therefore, I introduced the NOVECTOR directive. The code looks like this:

!DIR$ NOVECTOR
  do k=2,kmx
    mi = mi0 + k
    fx   = fx0/hn(mi)
    fy   = fy0/hn(mi)
    ! ...
    ! some more code
    ! ...
  enddo

The compiler yields the warning:

tflow_ptc.F90(1160): warning #6477: Fortran 2008 does not allow this statement or directive.
!DIR$ NOVECTOR

Interestingly, the assembler code shows v* commands in the NOVECTOR-do-loop and the run time get even worse. The FCFLAG environment variable for the compiler look as follows:

export FCFLAGS="-nofixed -convert big_endian -stand f08 -qopenmp -O2 -fp-model precise -g -debug inline-debug-info -parallel-source-info=2 -align array32byte -xAVX -I/sw/dataformats/hdf5/1.8.17/smp1/intel.16.0.3.210_threadsafe/include -I/sw/dataformats/netcdf/4.3.3.1/smp1/intel.16.0.3.210_threadsafe/include"

I use the Intel VTune Amplifier to evaluate the runtime. Therefore, the debug flags are included.

The ifort compiler version is: 16.0.3.210. There are some more versions available at our HPC-system but I did not try them yet.

My questions are:

• Are the VECTOR and NOVECTOR directives valid in Fortran 2008 code?
• I would expect that the NOVECTOR directive is ignored when it is not allowed. Is this a correct assumption?
• Is the NOVECTOR directive correctly used? In contrast to the !$omp directives there is no end-statement needed?

Thanks you for the help.

Kind Regards,

Daniel

Hello,

the following code leads to a crash in namelist read with the Intel compiler, but not any other Fortran compiler I have access to:

program ifort_nml_bug
  implicit none
  integer     :: n, k(5)
  namelist /nml/ n, k
  k = -1
  n = -1
  read(*,nml=nml)
  print *, k
end program ifort_nml_bug

The namelist input file:

&nml
k =
n = 2
/

The demo:

% ifort -g -traceback ifort_nml_bug.f90 && ./a.out < ifort_nml_bug.nml
forrtl: severe (17): syntax error in NAMELIST input, unit -4, file /proc/24888/fd/0, line 3, position 3
Image              PC        Routine            Line        Source
a.out              0806F9D0  Unknown               Unknown  Unknown
a.out              0804ED8B  Unknown               Unknown  Unknown
a.out              0804A06B  MAIN__                      7  ifort_nml_bug.f90
a.out              08049F66  Unknown               Unknown  Unknown

This occurs with ifort 14, 15, 16 & 17.0.

Commenting out the line with "n=2" in the namelist input makes the crash go away, so there is some input parsing problem.

Thanks,

Harald

I am running a source code on Ubuntu 14.04, 64 bit. And on 32 bit 10.04 Using intel Fortran. The tests differ substantially from each other.

next i tried using gfortarn compiler. same thing observed. 

the intel compiler and gfortran on 14.04 n 64 bits machines were identical and so were on 10.04  machine

Can some one help me in understanding the issue.

How can results match and which one should we rely upon.

thanks in anticipation

anand

Hello, I'm a student studying the geophysical exploration simulation (like modeling the elastic wave equation in FDM, FEM, etc).

I've known that when the simple situation like below,

real(8) :: a(100)
call test(a)
     :
subroutine test(b)
real(8) :: b(:)

in fortran, they allocate new memories in size of 'b' and the values of 'a' are copied to 'b'. After the subroutine is over, the values of 'b' are copied to 'a' and the memories of 'b' are deallocated.
But, what if the size of array 'a' is very large? Allocating new memory in size of 'a' can be memory consuming.

I recently found the pointer in fortran and I wonder about the memory usage of fortran. For example,

integer, pointer :: p1
real(8), pointer :: p2

Do the memory requirements of 'p1' and 'p2' are different? or the same?
Does the memory requirement of pointer is smaller than other types of variables (like real, complex, etc)?
Will it be of help to use subroutines which pass large arrays?

Thank you

Dear programmers,

In principle I develop my codes with C++/Python but today I am one of those lucky guys that must use a legacy code in fortran 77 parallelized with MPI. I have been using this code for years and it has been compiled and worked with different compilers, among which, intel 10.

Now we have installed the intel 2016 and it no longer works. It compiles successfully, runs...but the result is unexpected. All the data are 0.

Does it sound familiar to you? Do you know any compilation option to comply with the f77 standard and that could help me detect any error due to old format (for instance)?

I thank you very much in advance for any help.

Christophe

hi guys,

i am compiling my parallel application using ifort in my mac. it seems that i have a compatibility problem between  openmpi and intel ifort 2017. 

any suggestion?

when compiling a module, i have the following error:

p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px Menlo; color: #ffeec8; background-color: #8e3527; background-color: rgba(142, 53, 39, 0.75)}
span.s1 {font-variant-ligatures: no-common-ligatures}

glenan:/Users/mariano/SVN/Alya/Executables/unix |#117 > mpif90 -module Objects_x -c -fpp ../../Sources/kernel/parall/mod_communications.f90

/usr/local/include/mpif-sizeof.h(17): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX128_SCALAR is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX128_SCALAR]

      SUBROUTINE MPI_Sizeof_complex128_scalar(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(24): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX128_R1 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX128_R1]

      SUBROUTINE MPI_Sizeof_complex128_r1(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(31): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX128_R2 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX128_R2]

      SUBROUTINE MPI_Sizeof_complex128_r2(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(38): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX128_R3 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX128_R3]

      SUBROUTINE MPI_Sizeof_complex128_r3(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(45): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX128_R4 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX128_R4]

      SUBROUTINE MPI_Sizeof_complex128_r4(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(52): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX128_R5 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX128_R5]

      SUBROUTINE MPI_Sizeof_complex128_r5(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(59): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX128_R6 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX128_R6]

      SUBROUTINE MPI_Sizeof_complex128_r6(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(66): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX128_R7 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX128_R7]

      SUBROUTINE MPI_Sizeof_complex128_r7(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(73): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX32_SCALAR is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX32_SCALAR]

      SUBROUTINE MPI_Sizeof_complex32_scalar(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(80): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX32_R1 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX32_R1]

      SUBROUTINE MPI_Sizeof_complex32_r1(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(87): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX32_R2 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX32_R2]

      SUBROUTINE MPI_Sizeof_complex32_r2(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(94): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX32_R3 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX32_R3]

      SUBROUTINE MPI_Sizeof_complex32_r3(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(101): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX32_R4 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX32_R4]

      SUBROUTINE MPI_Sizeof_complex32_r4(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(108): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX32_R5 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX32_R5]

      SUBROUTINE MPI_Sizeof_complex32_r5(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(115): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX32_R6 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX32_R6]

      SUBROUTINE MPI_Sizeof_complex32_r6(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(122): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX32_R7 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX32_R7]

      SUBROUTINE MPI_Sizeof_complex32_r7(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(129): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX64_SCALAR is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX64_SCALAR]

      SUBROUTINE MPI_Sizeof_complex64_scalar(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(136): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX64_R1 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX64_R1]

      SUBROUTINE MPI_Sizeof_complex64_r1(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(143): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX64_R2 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX64_R2]

      SUBROUTINE MPI_Sizeof_complex64_r2(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(150): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX64_R3 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX64_R3]

      SUBROUTINE MPI_Sizeof_complex64_r3(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(157): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX64_R4 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX64_R4]

      SUBROUTINE MPI_Sizeof_complex64_r4(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(164): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX64_R5 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX64_R5]

      SUBROUTINE MPI_Sizeof_complex64_r5(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(171): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX64_R6 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX64_R6]

      SUBROUTINE MPI_Sizeof_complex64_r6(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(178): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_COMPLEX64_R7 is not distinguishable from this declaration. [MPI_SIZEOF_COMPLEX64_R7]

      SUBROUTINE MPI_Sizeof_complex64_r7(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(185): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_INT16_SCALAR is not distinguishable from this declaration. [MPI_SIZEOF_INT16_SCALAR]

      SUBROUTINE MPI_Sizeof_int16_scalar(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(192): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_INT16_R1 is not distinguishable from this declaration. [MPI_SIZEOF_INT16_R1]

      SUBROUTINE MPI_Sizeof_int16_r1(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(199): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_INT16_R2 is not distinguishable from this declaration. [MPI_SIZEOF_INT16_R2]

      SUBROUTINE MPI_Sizeof_int16_r2(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(206): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_INT16_R3 is not distinguishable from this declaration. [MPI_SIZEOF_INT16_R3]

      SUBROUTINE MPI_Sizeof_int16_r3(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(213): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_INT16_R4 is not distinguishable from this declaration. [MPI_SIZEOF_INT16_R4]

      SUBROUTINE MPI_Sizeof_int16_r4(x, size, ierror)

-----------------^

/usr/local/include/mpif-sizeof.h(220): error #5286: Ambiguous generic interface MPI_SIZEOF: previously declared specific procedure MPI_SIZEOF_INT16_R5 is not distinguishable from this declaration. [MPI_SIZEOF_INT16_R5]

      SUBROUTINE MPI_Sizeof_int16_r5(x, size, ierror)

-----------------^

/var/folders/77/ngbk1km12l1fl6dspttb14b80000gn/T/ifortseQu2w.i90(15484): catastrophic error: Too many errors, exiting

compilation aborted for ../../Sources/kernel/parall/mod_communications.f90 (code 1)

Dear all,

I have a question about subroutine arguments:

If I have a subroutine like this one

CALL SUBROUTINE(nElem)

SUBROUTINE(nElem)
REAL, DIMENSION(nElem) :: VECT1
REAL, DIMENSION(nElem) :: VECT2

....

and another one:

SUBROUTINE(nElem)

REAL,ALLOCATABLE,DIMENSION(:) :: VECT1,VECT2


ALLOCATE(VECT1(nElem))
ALLOCATE(VECT2(nElem))

...
...
....

DEALLOCATE(VECT1,VECT2)

Are these two procedures equivalent, also from computational time?

I ask this question because I have a program where I call several time a subroutine. I stategy could be allocate VECT1 and VECT2 outside in a specific module, but this does not seems very elegant and could create confusion in future.

Thanks to everyone

There doesn't seem to be any way to set the character delimiter if doing a namelist read from an internal file.  I see from.https://software.intel.com/en-us/node/678700 that the default delimiter is 'none'.  This prevents proper error checking, and seems contrary to Note 10.36 in the J3/10-007 copy of the 2008 standard.  Here's an example:

program abc
  character(len=32) :: fs
  character(len=1) :: xx(8)
  integer :: ios
  namelist /foo/ xx
  fs = "&foo xx = 34 /" ! Assign an integer value to the character variable.
  read(fs, nml=foo, iostat=ios)
  print *, 'xx(1)=', xx(1)
  print *, 'xx(2)=', xx(2)
  print *, 'xx(3)=', xx(3)
  print *, 'ios=', ios
end

Running the example produces this output:

$> ifort --version
ifort (IFORT) 17.0.2 20170213
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

$> ifort foo.f90 && ./a.out
 xx(1)=3
 xx(2)=
 xx(3)=
 ios=           0

This is consistent with the Rules for Namelist Reads link given above, but it's sure wierd.

#include "../lib/probeLocations.H"


int main(int argc, char *argv[])
{
    probeLocations(argc, argv);

    return 0;
}

I need to call the C++ function  probeLocations from f90 main code. How do I pass argc and argv from F90?

We observe deadlocks of long running OpenMP jobs with different executables built with ifort15. Reproduction of the issue typically takes >12 hours running with 12 threads on a Haswell platform.

In all cases the master thread deadlocks at an OpenMP PARALLEL directive in the inner iteration loop of a BiCGStab solver. That loop has 5 parallel blocks featuring sum and max reductions. We have several variants of that solver and the issue reproduces with either one. When the deadlock occurs the solver has done a total of >100 million iterations which translates to almost a billion thread forks and joins.

Has anybody come across a similar issue ? Any hints for further toubleshooting are appreciated.

Master thread stack trace:

     pthread_cond_wait,                                          FP=7ffc465e2c80
     __kmp_suspend_64,                                           FP=7ffc465e2de0
     _Z26__kmp_hyper_barrier_gather12barrier_typeP8kmp_infoiiPFvPvS2_ES2_, FP=7ffc465e2f10
     _Z18__kmp_join_barrieri,                                    FP=7ffc465e2fd0
     __kmp_internal_join,                                        FP=7ffc465e2ff0
     __kmp_join_call,                                            FP=7ffc465e3040
     __kmpc_fork_call,                                           FP=7ffc465e3130
     bicgstab_solv`bicgstab_solv_all,                            FP=7ffc466f1490

Worker threads stack trace:

     pthread_cond_wait,                                          FP=2b15bc3fe770
     __kmp_suspend_64,                                           FP=2b15bc3fe8d0
     _Z26__kmp_hyper_barrier_gather12barrier_typeP8kmp_infoiiPFvPvS2_ES2_, FP=2b15bc3fea00
     _Z18__kmp_join_barrieri,                                    FP=2b15bc3feac0
     __kmp_launch_thread,                                        FP=2b15bc3feb00
     _Z19__kmp_launch_workerPv,                                  FP=2b15bc3fecd0
     start_thread,                                               FP=2b15bc3fed70
     __clone,                                                    FP=2b15bc3fed78

The code I am working on is running fine on Windows.  When it is ported and  built on Linux, it fails on the  on eof our unit tests  with an error  – cannot write a file to working directory - in a directory that is open to write in.

Running the same Linux executable with strace, I get "too many open files" error trying to write the file.

Changing all buffered IO open statements from BUFFERCOUNT=4 to =1, now it runs with no errors.   Is there any known issue with buffered IO on Linux as opposed to WIndows?

thanks,

Scott

[code]:

module test_align

  implicit none

  real(8) ::a(5)
  !DIR$ ATTRIBUTES ALIGN:64 :: a

end module test_align

[compiling option]:

ifort -module include -fpp -std08 -assume byterecl -traceback -O3 -xMIC-AVX512 -qopt-report=5 -qopt-report-file=stdout -o -c ./test.o

[output]:

Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.2.174 Build 20170213

Compiler options: -I/soft/compilers/intel/compilers_and_libraries_2017.2.174/linux/mpi/intel64/include -I/soft/compilers/intel/compilers_and_libraries_2017.2.174/linux/mpi/intel64/include -module include -fpp -std08 -assume byterecl -traceback -O3 -xMIC-AVX512 -qopt-report=5 -qopt-report-file=stdout -c -o ./test.o

test.F90(6): warning #7025: This directive is not standard F2008.

!DIR$ ATTRIBUTES ALIGN:64 :: a

------^

    Report from: Interprocedural optimizations [ipo]

  WHOLE PROGRAM (SAFE) [EITHER METHOD]: false

  WHOLE PROGRAM (SEEN) [TABLE METHOD]: false

  WHOLE PROGRAM (READ) [OBJECT READER METHOD]: false

....

[question]:

I'm not sure whether the variable is aligned? What's the standard way to align data in F2008?

Hi,

the code below compiles with ifort 17.01 and gfortran 6.3, but not with ifort 17.02. The error message is:

"A private component name is accessible only within the module containing the type definition.   [A]
    this%a=1"

Module Mod_Parent
  Type, Abstract :: parent
    Integer, private :: a
  contains
    Procedure(SubSetA), Pass, deferred :: SetA
  End type parent
  Abstract Interface
    Subroutine SubSetA(this)
      Import parent
      Class(parent), Intent(InOut) :: this
    end subroutine
  end Interface
  Private :: SubSetA
End Module Mod_Parent
Module Mod_Child
  use Mod_Parent
  Type, extends(parent) :: Child
  contains
    Procedure, Pass :: SetA => SubSetA
  End type Child
  Interface
    Module Subroutine SubSetA(this)
      Class(child), Intent(InOut) :: this
    end subroutine
  end Interface
  Private :: SubSetA
End Module Mod_Child
Submodule(Mod_Child) Set
Contains
  Module Procedure SubSetA
    this%a=1
  End Procedure
End Submodule Set
Program Test
  use Mod_Child
  Type(Child) :: x
  call x%setA()
End Program Test

Is the code not standard compliant or is it a compiler bug. I thought the "inheritance vs private" clash was resolved with the advent of submodules.

Any idea?

Hello,

I am having difficulties with compiling the T-matrix fortran code. I have already written to the author and was told that the code is being used by hundreds of scientists and researchers and that the problem exists between my chair and keyboard :)
I attached the .zip file containing all files needed plus I exported errors which occured during compiling.
If you have any idea what I am doing wrong, please let me know.
Thank you very much for your response
Best regards
Ondrej Srom (UCT Prague)

Dear Sir,

In the latest release of "Parallel Universe" you state that the following code is vectorized efficiently thanks to avx512 instructions.

 nb = 0
 do ia=1, na ! line 23
 if (a(ia) > 0.) then
 nb = nb + 1 ! dependency
 b(nb) = a(ia) ! compress
 endif
 enddo

Using Fortran 90 intrinsics, one would equivalently write

n = count( a(1:na) > 0.)
b(1:n) = pack( a(1:na), mask=( a(1:na) > 0.) )

My question is whether your implementation of the intrinsics is always optimized better than old school (F77) equivalent code and thus is

to be preferred. Related to this, I read that icc an ifort share the same back-end, hence perform similar optimizations. But the array-based syntax of F90 provides the compiler with lots of information about data (in)dependency, which should help optimize better. Is this correct ? I am no expert, so I apologize in advance for being approximative. Thank you. 

Hi,

I have to port a windows fortran project to linux. The windows version uses CreateFileMapping,OpenFileMapping,MapViewOfFile and CopyMemory.

After some search I found, that linux has something similar with mmap and shm_open. Also I could use memcpy on both platforms.

My problem is that memcpy only works on windows and I always get undefined reference when I try to use shm_open for example. I guess I'm missing some compiler flags and/or using the wrong syntax for the external routines?

Here a little code example:

      module test

	  integer,parameter :: PROT_READ=1
      integer,parameter :: PROT_WRITE=2
      integer,parameter :: MAP_PRIVATE=2
      integer,parameter :: MAP_SHARED=1

      integer,parameter :: O_RDONLY=0
      integer,parameter :: O_WRONLY=1
      integer,parameter :: O_RDWR=2
      integer,parameter :: O_ACCMODE=3
      integer,parameter :: O_CREAT=512
      integer,parameter :: O_EXCL=2048
      integer,parameter :: O_TRUNC=1024

      integer,parameter :: S_IRUSR=1024
      integer,parameter :: S_IWUSR=512
      integer,parameter :: S_IXUSR=256
      integer,parameter :: S_IRGRP=64
      integer,parameter :: S_IWGRP=32
      integer,parameter :: S_IXGRP=16
      integer,parameter :: S_IROTH=4
      integer,parameter :: S_IWOTH=2
      integer,parameter :: S_IXOTH=1
      integer,parameter :: S_ISUID=16384
      integer,parameter :: S_ISGID=8192


	  interface
	  subroutine  memcpy(dest, src, n) bind(C,name='memcpy')
      use iso_c_binding
      INTEGER(c_intptr_t), intent(in):: dest
      INTEGER(c_intptr_t), intent(in):: src
      integer(c_size_t), value :: n
      end subroutine memcpy
	  end interface

	  interface
      INTEGER(c_intptr_t) function mmap(addr,len,prot,flags,fildes,off) bind(c,name='mmap')
      use iso_c_binding
      integer(c_int), value :: addr
      integer(c_size_t), value :: len
      integer(c_int), value :: prot
      integer(c_int), value :: flags
      integer(c_int), value :: fildes
      integer(c_size_t), value :: off
      end function mmap
      end interface

      interface
      integer(c_int) function munmap(addr, len) bind(c,name='munmap')
      use iso_c_binding
      integer(c_int), value :: addr
      integer(c_size_t), value :: len
      end function munmap
      end interface

      interface
      integer(c_int) function shm_open(name,oflag,mode) \
	  bind(c,name='shm_open')
      use iso_c_binding
      character(kind=c_char) :: name(*)
      integer(c_int), value :: oflag
      integer(c_int16_t), value :: mode
      end function shm_open
      end interface

      interface
      integer(c_int) function shm_unlink(name) bind(c,name='shm_unlink')
      use iso_c_binding
      character(kind=c_char) :: name(*)
      end function shm_unlink
      end interface

	  end module

	  program FortranTest
	  use iso_c_binding
	  use test
      implicit none

      real*8, allocatable, dimension(:) :: testarr, testarr2
      integer :: i, oflag, sflag

	  oflag = ior(O_RDWR, O_CREAT)
	  sflag = ior(S_IWUSR, S_IRUSR)

	  i = shm_open('/home/lbb/FEAP/test/test123.blub', oflag, sflag)

      allocate(testarr(10))
	  allocate(testarr2(10))

      do i=1,10
      testarr(i) = 1
	  testarr2(i) = 2
      end do

	  print *, 'testarr'
	  do i=1,10
      print *, testarr(i)
      end do

	  print *, 'testarr2'
	  do i=1,10
      print *, testarr2(i)
      end do

	  print *, 'call memcpy'
	  call memcpy(loc(testarr(1)), loc(testarr2(1)), 16)

	  print *, 'testarr'
	  do i=1,10
      print *, testarr(i)
      end do

      read (*,*)

      end program FortranTest

The makefile looks like this:

# fortran compiler = intel fortran
fcomp = ifort
switch = -module obj -w -f77rtl -fpp -qopenmp -parallel -intconstant -zero -assume:byterecl -check:pointers -check:bounds -check:uninit
baseList = test2.for
baseObj = $(baseList:.for=.o)

all: base test

base: $(baseObj)
%.o: %.for
	$(fcomp) $(switch) -c $< -o obj/$(notdir $@)

test: base
	$(fcomp) $(switch) obj/*.o -o obj/test2 -mkl -shared-libgcc -threads -cxxlib

clean:
	@echo "target clean: delete obj/*"
	rm -f obj/*

If I run this example (without shm_open) on windows I get the expected result:

testarr
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
 testarr2
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
 call memcpy
 testarr
   2.00000000000000
   2.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000

On linux I get :

lbb@dev-01:~/FEAP/test$ obj/test2
 testarr
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
 testarr2
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
   2.00000000000000
 call memcpy
 testarr
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000
   1.00000000000000

So memcpy isn't working as expected (maybe the c function isn't called at all?)

So any hints for me?

Kind regards,

Stephan

I am trying to compile a model code with mpiifort. In the makefile compiler flags are mentioned as "-Vaxlib" which is not supported in the new version of compilers I have.

is there any substitute to this flag ?

I am getting following series of errors:

ifort: command line remark #10148: option '-Vaxlib' not supported

oceanforc.o: In function `MAIN__':
oceanforc.f:(.text+0xd67): undefined reference to `nf_open_'
oceanforc.f:(.text+0xd96): undefined reference to `nf_inq_'
oceanforc.f:(.text+0xde2): undefined reference to `nf_inq_dim_'
oceanforc.f:(.text+0x10d0): undefined reference to `nf_inq_varid_'
oceanforc.f:(.text+0x1131): undefined reference to `nf_get_vara_double_'
oceanforc.f:(.text+0x1144): undefined reference to `nf_close_'
oceanforc.f:(.text+0x2419): undefined reference to `nf_create_'
oceanforc.f:(.text+0x2443): undefined reference to `nf_def_dim_'
oceanforc.f:(.text+0x2472): undefined reference to `nf_def_dim_'
oceanforc.f:(.text+0x2494): undefined reference to `nf_def_dim_'
oceanforc.f:(.text+0x24b6): undefined reference to `nf_def_dim_'
oceanforc.f:(.text+0x24d8): undefined reference to `nf_def_dim_'
oceanforc.o:oceanforc.f:(.text+0x2507): more undefined references to `nf_def_dim_' follow
oceanforc.o: In function `MAIN__':
oceanforc.f:(.text+0x2629): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x266c): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x269f): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x26d2): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2722): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x2765): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2798): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x27cb): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x281b): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x285e): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2891): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x28c4): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2914): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x2957): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x298a): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x29bd): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2a0d): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x2a50): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2a83): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2ab6): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2b06): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x2b49): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2b7c): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2baf): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2c1b): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x2c5e): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2c91): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2cc4): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2d30): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x2d73): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2da6): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2dd9): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2e45): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x2e88): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2ebb): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2eee): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2f21): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x2f8d): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x2fd0): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x3003): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x3036): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x3069): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x30d5): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x3118): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x314b): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x317e): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x31b1): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x321d): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x3260): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x3293): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x32c6): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x3332): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x3375): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x33a8): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x3414): undefined reference to `nf_def_var_'
oceanforc.f:(.text+0x3457): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x348a): undefined reference to `nf_put_att_text_'
oceanforc.f:(.text+0x34a4): undefined reference to `nf_enddef_'
oceanforc.f:(.text+0x34fe): undefined reference to `nf_put_vara_double_'
oceanforc.f:(.text+0x3558): undefined reference to `nf_put_vara_double_'
oceanforc.f:(.text+0x35b2): undefined reference to `nf_put_vara_double_'
oceanforc.f:(.text+0x360c): undefined reference to `nf_put_vara_double_'
oceanforc.f:(.text+0x3666): undefined reference to `nf_put_vara_double_'
oceanforc.o:oceanforc.f:(.text+0x36c0): more undefined references to `nf_put_vara_double_' follow
oceanforc.o: In function `MAIN__':
oceanforc.f:(.text+0x39e0): undefined reference to `nf_close_'
make[1]: *** [oceanforc.x] Error 1
make[1]: Leaving directory `/home/ROMS/RSM_ROMS/roms/Utils'
make: *** [utils] Error 2
++ exit 8

Hi,

one of my programs is crashing when runnig a threaded version. When running it inside gdb the output left me helpless:

[New LWP 397493]

Program received signal SIGSEGV, Segmentation fault.
[Switching to LWP 397493]
0x0000000001dad557 in _INTERNAL_25_______src_kmp_barrier_cpp_5de9139b::__kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) ()

gdb bt yielded:

#0  0x0000000001dad557 in _INTERNAL_25_______src_kmp_barrier_cpp_5de9139b::__kmp_hyper_barrier_release(barrier_type, kmp_info*, int, int, int, void*) ()
#1  0x0000000001dae38b in __kmp_fork_barrier(int, int) ()
#2  0x0000000001d150c0 in __kmp_launch_thread ()
#3  0x0000000001d5d341 in _INTERNAL_26_______src_z_Linux_util_cpp_47afea4b::__kmp_launch_worker(void*) ()
#4  0x0000000001eb3ff7 in start_thread ()
#5  0x0000000001f2507b in clone ()

To get an idea about parts of the structure of the program a code snippet which mimics what the program is doing is given below. However, this is just for examplification, I have not tested whether the snippet will produce the same segfaut.

Module Mod_Root
  Implicit none
  Type :: root
  End type root
End Module Mod_Root
Module Mod_Sigma
  use Mod_Root, only: root
  Implicit None
  Type, abstract, extends(root) :: Sigma
    Real, Pointer, contiguous :: PreMult(:,:), PostMult(:,:)
  contains
    Procedure(SubMult), PAss, Public, Deferred :: Mult
  end type Sigma
  Abstract Interface
    Subroutine SubMult(this)
      Import Sigma
      Class(Sigma), Intent(In) :: this
    End Subroutine SubMult
  End Interface
  Private :: SubMult
End Module Mod_Sigma
Module Mod_Sigma_Type_A
  use Mod_Sigma, only: Sigma
  Type, extends(Sigma) :: Sigma_Type_A
    Real, Allocatable :: Mat(:,:,:)
  contains
    Procedure, Pass, Public :: Mult=>SubMult
  End type Sigma_Type_A
  Private :: SubMult
contains
  Subroutine SubMult(this)
    Implicit None
    Class(Sigma_Type_A), Intent(In) :: this
    Integer :: i
    Do i=1,size(this%Mat,3)
      this%PostMult(i,:)=matmul(this%PreMult(i,:),this%Mat(:,:,i))
    End Do
  End Subroutine SubMult
End Module Mod_Sigma_Type_A
Module Mod_Sigma_Type_B
  use Mod_Sigma, only: Sigma
  Type, extends(Sigma) :: Sigma_Type_B
    Real, Allocatable :: Mat(:,:)
  contains
    Procedure, Pass, Public :: Mult=>SubMult
  End type Sigma_Type_B
  Private :: SubMult
contains
  Subroutine SubMult(this)
    Implicit None
    Class(Sigma_Type_B), Intent(In) :: this
    this%PostMult=matmul(this%PreMult,this%Mat)
  End Subroutine SubMult
End Module Mod_Sigma_Type_B
Module Mod_Struct
  use Mod_Root, only: root
  use Mod_Sigma, only: sigma
  Type,extends(root), abstract :: Struct
    Class(Sigma), Allocatable :: Sigma
  Contains
    Procedure(SubMult), Public, PAss, Deferred :: Mult
  End type Struct
  Type :: StructPt
    CLass(Struct), Pointer :: pt
  end type StructPt
  Abstract interface
    Subroutine SubMult(this)
      Import Struct
      Class(Struct), Intent(InOut), Target :: this
    end Subroutine SubMult
  End interface
End Module Mod_Struct
Module Mod_Struct_A
  use Mod_Struct
  Type, extends(Struct) :: Struct_Type_A
    Real, Allocatable :: Mat1(:,:), Mat2(:,:)
  Contains
    Procedure, Pass, Public :: Mult => SubMultSigma
  End type Struct_Type_A
  Private :: SubMultSigma
contains
  Subroutine SubMultSigma(this)
    Implicit None
    Class(Struct_Type_A), Intent(InOut), Target :: this
    this%Sigma%PreMult=>this%Mat1
    this%Sigma%PostMult=>this%Mat2
    call this%Sigma%Mult()
  End Subroutine SubMultSigma
End Module Mod_Struct_A
Program Test
  use Mod_Struct
  use Mod_Struct_A
  use Mod_Sigma_Type_A
  use Mod_Sigma_Type_B
  Type(Struct_Type_A), Target :: a, b
  Class(StructPt), Allocatable :: x(:)
  Integer :: i
  allocate(Sigma_Type_A::a%sigma)
  allocate(Sigma_Type_B::b%sigma)
  Allocate(x(2))
  x(1)%pt=>a;x(2)%pt=>b
  !$OMP PARALLEL DO PRIVATE(i)
  Do i=1,2
    call x(i)%pt%Mult()
  End Do
  !$OMP END PARALLEL DO
End Program Test

The segfault in my progrram occurs in a location similar to when calling x(i)%pt%Mult, but only if b%sigma has been allocated as type "Sigma_Type_B". If both, a and b, has been allocated as type "Sigma_Type_A", the program runs fine invaribaly of the size of the relevant arrays. Moreover, threaded or unthreaded the pogram always runs when the involved arrays are small. However, when arrays occupy up to 200GB of RAM and different type allocations are used, it crashes.

ifort version is 17.01, linux version is centos 7 kerner 3.10, stack size is set to unlimited, omp_stacksize to 32MB.

compiler flags were

-assume byterecl -warn nounused -warn declarations -O0 -static -check all -traceback -warn interface -check noarg_temp_created -mkl=parallel -qopenmp

Neither at compile time nor at run time any errors or warnings occured. The pogram ran on a machine with 56 "Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz" processors and 512GB RAM.

Given the compiler flags I used and running the program inside gdb I am running out of ideas at this point. It would be great if one form Intel could look into this. I could suppliy an executable and a data set which triggers the segfault.

Thanks a lot.

I am using the latest code CAMB 2017-Jan with latest OSX 10.12.3 and latest ifort 17.0.2，when I run make there comes

Kongs-MacBook-Pro:CAMB-Jan2017 jiangjie$ make
mkdir -p Release
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c constants.f90 -o Release/constants.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c utils.F90 -o Release/utils.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c subroutines.f90 -o Release/subroutines.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c inifile.f90 -o Release/inifile.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c power_tilt.f90 -o Release/power_tilt.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c recfast.f90 -o Release/recfast.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c reionization.f90 -o Release/reionization.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c modules.f90 -o Release/modules.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c bessels.f90 -o Release/bessels.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c equations.f90 -o Release/equations.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c halofit_ppf.f90 -o Release/halofit_ppf.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c lensing.f90 -o Release/lensing.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c SeparableBispectrum.F90 -o Release/SeparableBispectrum.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c cmbmain.f90 -o Release/cmbmain.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ -c camb.f90 -o Release/camb.o
ifort -fast -W0 -WB -fpp  -qopenmp -module Release -IRelease/ Release/constants.o  Release/utils.o   Release/subroutines.o Release/inifile.o  Release/power_tilt.o  Release/recfast.o Release/reionization.o Release/modules.o Release/bessels.o Release/equations.o Release/halofit_ppf.o Release/lensing.o Release/SeparableBispectrum.o Release/cmbmain.o Release/camb.o inidriver.F90 -cxxlib -o camb
mkdir -p Releaselib
ifort -shared -fpic -fast -W0 -WB -fpp  -qopenmp -module Releaselib -IReleaselib/ -c constants.f90 -o Releaselib/constants.oifort: command line error: '-fminshared' conflicts with '-fpic'
make: *** [Releaselib/constants.o] Error 1

I know nothing about fortran and just want to run the code, can anybody help me fix the problem? Thanks very much.

How does intel Fortran on Linux handle string length arguments, mixed string length or all at the end of arg list?   Is there an option?  I did not see it in the man page.  on windows, there is /iface:mixed_str_len_args 

thanks

Scott