A number of years ago, we switched over to performing automatic interface generation and compile-time interface checking to help check our coding habits.  One issue we're repeatedly running into however is that we run into a chicken-and-egg problem when compiling, since you will only have the module files available for a file after it has been compiled.  Thus, the first routine to be compiled will not be checked against any modules, the second will only be checked against the first, etc.  We could take two passes through the source, compiling everything and generating modules, then deleting the compiled objects, and taking a second pass compiling again, this time checking interfaces, but with an extensive code base this would add significantly to our compile process.

I can't seem to find a compile flag that would just generate a set of interface files for the input source and stop prior to compilation.  If such an option doesn't exist, can we do a feature request for one?  Assuming the interface generation step is relatively lightweight, this would allow us to take a fast pass through all the code to generate the interface files (much in the same way we currently do with dependency generation for GNU 'make'), followed by a single pass through the source tree to compile once all of the interface files are available.

Also, related question: is there a way to compile a user-written .f90 interface file into a binary .mod file?

I am facing this problem with mpiifort:

make mpi=openmpi MPIdir=/home/singh/src all -f Makefile
mkdir -p ./bin
mkdir -p ./lib
make[1]: Entering directory `/home/singh/ukrmol-out/source/libouter'
mpiifort -i8 -w -p -openmp -i8 -O0  -c borncros.f
make[1]: mpiifort: Command not found
make[1]: *** [borncros.o] Error 127
make[1]: Leaving directory `/home/singh/ukrmol-out/source/libouter'
make: *** [SUBDIRS] Error 2

The Fortran 2008 standard specified that intrinsilcs ACOS, ASIN, ATAN take complex arguments.
It seems ifort 17.0.0 20160315 does not yet accept complex for these intrinsics.
Any estimate for when this might be supported?
Or perhaps I missed some compiler option to enable this?

Thanks

Anton

Have Intel Parallel Studio XE Cluster Edition Version 16.0 update 3 installed on Cent O/S 7.2 and am having debugger issues (gdb-ia).

Using Eclipse neon on KNL with PHOTRAN extension.

The application is

C main compiled using the Intel mpiicc (the C main is an MPI process stub)
C++ code with OpenMP (num threads set to 1)
Intel Fortran .so library which is being debugged

gdb-ia version 7.8-16.0.768
Note, on startup it emits

warning: Cannot parse .gnu_debugdata section; LZMA support was disabled at compile time

First issue I had, but I believe is corrected now, is the documentation on how to install and use Intel's version of gdb (gdb-ia) has incorrect instructions. The documentation references compilervars.sh not psxevars.sh...
... nor debuggervars.sh (in a different folder)

Please correct the documentation.

Second issue, which may be the source of my third (and pressing) issue is, the "standard" gdb debugger uses a command file named .gdbinit. The Intel documentation does not state if this file is to be used, or if there is an alternate "init" file to be used (.gdb-iainit).
Is there an alternate gdb command file?

Now for the pressing issue.

I am trying to find out why a convergence routine is failing to converge in the Fortran .so file. My SOP is to let the program run until I think it is hung, then press Pause all (||) in the Eclipse neon IDE.

Usually this breaks into the hung Fortran .so library... and I can see in the Variables Window the function's call arguments and local variables.

The issue though, is when I go up the call stack, the variables will not display. If I go back down to the lowest level, the variables display.

When I compile the Fortran .so file with Provide Frame Pointer, the call stack does not show the C++ code stack. But it does show when omitting the frame pointer.

After I Pause (SIGINT) into gdb-ia, in the Fortran .so library, I am unable to Step Over/Into/Out, or Continue

But note, if I revert back to gdb, I can Step Over/Into/Out, and Continue, however, I still have the missing variables up the call stack.

If anyone has some hints on how to resolve this, I'd appreciate the education.

Additional note. When I use gdb (so I can step), it usually runs for several seconds (10's of seconds) then something terminates the application.

Is there a process killer that kills what it thinks is a hung job? (and if so, how to disable)

Jim Dempsey

hi,

I am trying to compile source codes and created .optrpt but executable output file is not created. The following remark I got during MAKEFILE run:

ifort: remark #10397: optimization reports are generated in *.optrpt files in the output location

and please find the attached MAKEFILE, outer and .optrpt

Please advice me on this problem.

Dear Intel support team

For the following code I obtain an error:

program test
  implicit none
  type SomeType
    real, pointer, contiguous :: x(:) => null()
  end type
  type(SomeType) :: t

  allocate(t%x(10))
  call doSomething(t)
  write(*,*) t%x
contains

  subroutine doSomething(myT)
    class(*), intent(in) :: myT

    select type(myT)
    type is (SomeType)
      ! not allowed!
      ! myT%x => null()

      ! allowed!
      myT%x = 7.

      ! workaround
      call assign7(myT%x)

    class default
      write(*,*) 'error'
      call exit(1)
    end select

  end subroutine

  subroutine assign7(x)
    real, intent(out) :: x(:)
    x = 7
  end subroutine

end program test

The error message shown is:

> ifort --version
ifort (IFORT) 16.0.3 20160415> ifort test.f90
test.f90(22): error #6780: A dummy argument with the INTENT(IN) attribute shall not be defined nor become undefined.   [MYT]
      myT%x = 7.
------^
compilation aborted for test.f90 (code 1)

As x is a pointer changing its value should be allowed though. Everything works fine, when "myT" is just declared as "type(SomeType), intent(in)" (without using "class(*)" polymorphism)!

As a workaround it is possible to call a subroutine to modify "myT%x"...

Regards

Melven

Hello, I'd like to embed version number information in a shared object (.so) binary during compiling and linking.  It looks like there is not a resource file available on Linux like on Windows with a version.rc resource file.  When building a DLL on Windows I can include a version.rc resource file and use the rc.exe resource compiler to get the version.res file to link into the DLL.  In the DLL properties/Details it gives the File Version number as 1.0.0.0 (similar discussion in: https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/281529 ).

Is there another approach used to embed version information for the shared object binary on Linux that can later be extracted by an external program?

I've seen that one convention on Linux is to append the version number to the .so file: libname.so.1.0.0

Perhaps I should add a few parameter statements in the Fortran to save the version numbers or string that could be accessed through an externally available routine to return the version information.

Thanks for your suggestions.
Greg T.

Running PS XE Cluster Edition 2017, IVF Fortran .so file with OpenMP tasking.

Running on KNL with 256 logical processors.

The number of pending tasks being submitted is very large, could be on the order of 10,000-100,000.

Receiving:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffd113bd300 (LWP 172021)]
0x00007ffff5edb16b in __kmp_remove_my_task (thread=<optimized out>, gtid=<optimized out>, task_team=<optimized out>, is_constrained=<optimized out>) at ../../src/kmp_tasking.c:1674
1674    ../../src/kmp_tasking.c: No such file or directory.

I will add defensive code to throttle down the number of pending tasks. Then see what happens. kmp_tasking.c should not crash in any event.
BTW stack limit set at 16MB (2MB is probably enough).

Jim Dempsey

Intel Parallel Studio XE 2017, including Intel Fortran Compiler 17.0, is now available from the Intel Registration Center. Release notes can be found here.

Among the new F2008 features are:

• TYPE(intrinsic-type)
• Pointer initialization
• Implied-shape PARAMETER arrays
• Extend EXIT statement to all valid construct names
• Support BIND(C) in internal procedures

There is also new support for OpenMP 4.5 features, an option to align the code for loops and more.

A significant change in this release is that the default for intrinsic assignment to allocatable arrays is now to do the automatic (re)allocation if necessary, as specified by the standard. In past releases you needed to specify the -assume realloc_lhs option to get this behavior. In some applications the additional checking may affect performance - you can revert to the previous behavior by specifying norealloc_lhs or the new option -nostandard-realloc-lhs.

Another change is to correct and make consistent how the compiler treats nonstandard conversions between numeric and LOGICAL types. Please see the release notes for more details.

The following code throws floating point overflow in __svml_powf4_h9 when compiled with -O3 and -O2:

  do i        = 1,nkd2p1

     x2 = abs ((i-1)*delk/kright)

     x2          = -apar*x2**bex

     wrkr(i*2-1) = x2

  enddo

Disable fpe check the program runs fine and give correct result. We have seen these kind of FPE caused by vectorise from time to time. By explicitly declare "!DIR$ NOVECTOR" does the trick but will have impact on performance.

The loop seems to be perfectly fine for vectorize and the numerical values in the result are far from overflow. I am wondering why overflow will happen?

The machine code when it crash:

   0x00000000012349f0 <+784>:   vaddpd %xmm3,%xmm2,%xmm5
   0x00000000012349f4 <+788>:   vpaddq %xmm7,%xmm4,%xmm1
   0x00000000012349f8 <+792>:   vpaddq %xmm8,%xmm5,%xmm2
=> 0x00000000012349fd <+797>:   vcvtpd2ps %xmm1,%xmm3
   0x0000000001234a01 <+801>:   vcvtpd2ps %xmm2,%xmm4
   0x0000000001234a05 <+805>:   vmovlhps %xmm4,%xmm3,%xmm1
   0x0000000001234a09 <+809>:   test   %eax,%eax
   0x0000000001234a0b <+811>:   jne    0x1234a4f <__svml_powf4_h9+879>
   0x0000000001234a0d <+813>:   vmovups 0x30(%rsp),%xmm8
   0x0000000001234a13 <+819>:   vmovaps %xmm1,%xmm0

(gdb) p $xmm3                                                                                                                                                                                                                                                                             
$1 = {v4_float = {1.42776291e+31, 0.708184719, -6.739982e+24, 0.690881014}, v2_double = {0.00032494041370586407, 0.00025734792206721777}, v16_int8 = {-126, 53, 52, 115, -104, 75, 53, 63, -27, 103, -78, -24, -108, -35, 48, 63}, v8_int16 = {13698, 29492, 19352, 16181, 26597, -5966, 
    -8812, 16176}, v4_int32 = {1932801410, 1060457368, -390961179, 1060167060}, v2_int64 = {4554629716295038338, 4553382854900475877}, uint128 = 0x3f30dd94e8b267e53f354b9873343582}

The finalization of a non-present optional intent(out) allocatable dummy argument produces a segmentation fault at runtime when the following code is compiled with ifort 16.0.3. This is the same issue as reported some years ago in https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux... (topic closed) and faintly ressembles https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux... (pointer instead of allocatabe).

module m
    ! finalized t
    type :: t
    contains
        final :: tfinal
    end type
contains
    subroutine tfinal(a)
        type(t), intent(inout) :: a
    end subroutine

    ! pass optional t, finalized on entry
    subroutine pass(a)
        type(t), allocatable, intent(out), optional :: a
        print *, 'passed'
    end subroutine
end module

program p
    use m
    type(t), allocatable :: a

    call pass(a)        ! ok
    call pass()         ! segfault
end program

It would certainly be nice to have a fix for this, or some ideas for workarounds without having to change the dummy's attributes.

Kind regards
Ferdinand

PS: Syntax-highlighting as suggested using (left-angle bracket) pre class="brush:fortran"(right-angle bracket) doesn't work in my post.

Hi,  

I was part of the beta program for the intel 2017 compiler. Everything worked fine. We just updated to the official release and i have a new issue with the message : 

(.text+0x51): relocation truncated to fit: R_X86_64_32 against symbol `mod_parallel_defs_mp_comm_' defined in COMMON section in avbp.a(mod_parallel_defs.o)

the avbp.a file is an archive we generate ourself from .o files with the  ar r  command … I have seen in the forum that switching to dynamic libraries might solve the issue ( ticket from 2011 ) but this is not a librarie juste an archive to avoid having a very large linking command that fails on some systems ( we have a lot of files .. )

Any suggestions ? Why did the behavior change between the beta and the release ? 

We have this issue on a KNL system.

thank you

hi sir,

i am having trouble installing the software on my ubuntu os.

as given in the installation guide i tried running the command install_GUI.sh and install.sh in the terminal but at first it showed no file found

then i changed the directory where the file was downloaded but still it shows the same

I expect that whether textblock is declared len=: or len=80 that the following code would produce a successful assignment to textblock; but in one case textblock is unallocated on version 16.  Is this still an issue with V 17?

! place in file testit.F90; compile with ifort, then "ifort -DCOLON"
! ifort testit.F90 -o fixedlen;./fixedlen
! ifort -DCOLON testit.F90 -o colon;./colon
program testit
implicit none
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
#ifdef COLON
character(len=:),allocatable :: textblock(:)
character(len=*),parameter   :: string='LEN=:'
#else
character(len=80),allocatable :: textblock(:)
character(len=*),parameter   :: string='LEN=80'
#endif
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
integer                      :: i
   textblock=[ character(len=40) :: &
   '#########',&
   '#       #',&
   '#       ###################',&
   '#                         #',&
   '#             #############',&
   '#             #',&
   '###############']
   write(*,*)   'FOR ',string
   write(*,*)   'ALLOCATED ',allocated(textblock)
   write(*,*)   'SIZE      ',size(textblock)
   if(size(textblock).gt.0)then
      write(*,*)'LEN       ',len(textblock(1))
   endif
   write(*,'(a)')(trim(textblock(i)),i=1,size(textblock))
end program testit
 

Greetings,

I am developing a program to study the dynamics of a system of particles in a cubic box with periodic boundary conditions. I would like to take advantage of auto-vectorization to expedite computations. To that end, I have created a data structure for storing the position, orientation, force, and torque vectors (among quantities of interest). 

If I understood correctly the documentation on auto-vectorization, I can request the compiler to align the data structure (or derived-type) to a 32-bit boundary and use the sequence attribute to pack the components of the structure (no-padding). I am interested in aligning data to 32-bit boundaries since I am targeting the program to run in AVX processors. The problem that I am facing is that none of the components becomes aligned despite the fact that the data structure is requested to be aligned to a 32-bit boundary.

To ease the troubleshooting, I am posting a minimalistic version of the code here (with comments for clarity of the reader):

module dynamics
    ! Description:
    ! Defines the principal data structure that stores information about the particles
    ! in the system. To take advantage of auto-vectorization the data is organized
    ! as a Structure of Arrays (SoA).
    use, intrinsic :: iso_fortran_env
    implicit none
    type data
        sequence
        ! position vector
        real(kind = real64), allocatable :: r_x(:);
        real(kind = real64), allocatable :: r_y(:);
        real(kind = real64), allocatable :: r_z(:);
        ! orientation vector (director)
        real(kind = real64), allocatable :: d_x(:);
        real(kind = real64), allocatable :: d_y(:);
        real(kind = real64), allocatable :: d_z(:);
        ! force vector
        real(kind = real64), allocatable :: F_x(:);
        real(kind = real64), allocatable :: F_y(:);
        real(kind = real64), allocatable :: F_z(:);
        ! torque vector
        real(kind = real64), allocatable :: T_x(:);
        real(kind = real64), allocatable :: T_y(:);
        real(kind = real64), allocatable :: T_z(:);
        ! displacement vector (the prefix `d' stands for delta or difference)
        real(kind = real64), allocatable :: dr_x(:);
        real(kind = real64), allocatable :: dr_y(:);
        real(kind = real64), allocatable :: dr_z(:);
        ! particle ID array
        integer(kind = int32), allocatable :: ID(:);
        ! padding array, such that we have an equivalent of 16 arrays of 64 bits each
        integer(kind = int32), allocatable :: padding(:);
    end type data

    private
    public data

end module dynamics

program alignment_test
    ! Minimalistic program to test the alignment of derived-types.
    use, intrinsic :: iso_fortran_env
    use dynamics
    implicit none

    ! particle data structure, aligned to 32-bits
    type(data), target :: pdata;
    !dir$ attributes align: 32 :: pdata

    ! number of particles in the system
    integer(kind = int32), parameter :: n_pdata = 64;

    ! captures the status returned by allocate/deallocate functions
    integer(kind = int32) :: alloc_stat;

    ! pointer to access the components of the data structure
    real(kind = real64), pointer, contiguous :: pr_x(:);
    real(kind = real64), pointer, contiguous :: pr_y(:);
    real(kind = real64), pointer, contiguous :: pr_z(:);

    allocate( pdata %r_x(n_pdata), pdata %r_y(n_pdata), pdata %r_z(n_pdata),&
        pdata %d_x(n_pdata), pdata %d_y(n_pdata), pdata %d_z(n_pdata),&
        pdata %F_x(n_pdata), pdata %F_y(n_pdata), pdata %F_z(n_pdata),&
        pdata %T_x(n_pdata), pdata %T_y(n_pdata), pdata %T_z(n_pdata),&
        pdata %dr_x(n_pdata), pdata %dr_y(n_pdata), pdata %dr_z(n_pdata),&
        pdata %ID(n_pdata), pdata %padding(n_pdata), stat=alloc_stat );

    if ( alloc_stat /= 0 ) then
        stop "insufficient memory to allocate the data structure, program stopped"
    end if

    pr_x => pdata %r_x;
    pr_y => pdata %r_y;
    pr_z => pdata %r_z;

    ! assign pretend values to the components of the position vector of the particles

    !dir$ assume_aligned pr_x: 32
    pr_x = 0.0d+0;
    !dir$ assume_aligned pr_y: 32
    pr_y = 0.0d+0;
    !dir$ assume_aligned pr_z: 32
    pr_z = 0.0d+0;


    ! free structure from memory
    deallocate( pdata %r_x, pdata %r_y, pdata %r_z,&
        pdata %d_x, pdata %d_y, pdata %d_z,&
        pdata %F_x, pdata %F_y, pdata %F_z,&
        pdata %T_x, pdata %T_y, pdata %T_z,&
        pdata %dr_x, pdata %dr_y, pdata %dr_z,&
        pdata %ID, pdata %padding, stat=alloc_stat );
    if ( alloc_stat /= 0 ) then
        stop "unexpected error, failed deallocate the data structure..."
    end if

end program

The program was compiled in the following manner:

ifort -g -traceback -check all -align nosequence  -O0 alignment_test.f90

Here is the output generated at runtime:

forrtl: severe (408): fort: (28): Check for ASSUME_ALIGNED fails for 'PR_X' in routine 'ALIGNMENT_TEST' at line 77.

Image              PC                Routine            Line        Source             
a.out              0000000000407786  Unknown               Unknown  Unknown
a.out              000000000040454F  MAIN__                     77  alignment_test.f90
a.out              0000000000402F1E  Unknown               Unknown  Unknown
libc.so.6          0000003B1F81ED5D  Unknown               Unknown  Unknown
a.out              0000000000402E29  Unknown               Unknown  Unknown

and the version of the Fortran compiler is the following:

ifort --version
ifort (IFORT) 16.0.3 20160415
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

Thanks in advance for your help,
Misael

Dear all,

there is an issue, I've found with user defined assignment when using the ifort compiler (version 16.0). Let's have a basic type with user defined assignment (as TBP) and an extending type which does not define its own assignment. When a non-polymorphic instance of the extended type is defined, an assignment to it invokes the user defined assignment of the base type. When I understood the explanations of Malcom Cohen (as response to my nagfor compiler bug report in this matter), this should, however, not happen. So, in the example below, the assignBasic() routine should not be invoked (as it happens in the ifort compiled binary).

module typedef
  implicit none

  type :: Basic
  contains
    procedure :: assignBasic
    generic :: assignment(=) => assignBasic
  end type Basic

  type, extends(Basic) :: Extended
  end type Extended

contains

  subroutine assignBasic(this, other)
    class(Basic), intent(out) :: this
    type(Basic), intent(in) :: other

    print "(A)", "assignBasic invoked"

  end subroutine assignBasic

end module typedef


program test
  use typedef
  implicit none

  type(Extended) :: ext
  print "(A)", "Non-polymorphic assignment"
  ext = Extended()

end program test

The following code does not compile with Intel Fortran v16, v17, on x86-64 Linux:

module mymod
implicit none

type :: mytype
  private
  integer :: a
  contains
  procedure,private :: eq
  generic :: operator(==) => eq
endtype mytype

interface mytype
  module procedure :: constructor
endinterface mytype

contains

type(mytype) function constructor(a)
  integer,intent(in),optional :: a
  if(present(a))then
    constructor % a = a
  else
    constructor % a = 0
  endif
endfunction constructor

logical function eq(m0,m1)
  class(mytype),intent(in) :: m0
  class(mytype),intent(in) :: m1
  eq = m0 % a == m1 % a
endfunction eq

endmodule mymod

module wrapper_module
use mymod,only:mytype
endmodule wrapper_module

program test
use wrapper_module
implicit none

write(*,*)mytype() == mytype(0)

endprogram test

The compiler does not seem to resolve the overloaded == operator for mytype:

$ ifort test.f90
test.f90(44): error #6355: This binary operation is invalid for this data type.
write(*,*)mytype() == mytype(0)
----------^
test.f90(44): error #6355: This binary operation is invalid for this data type.
write(*,*)mytype() == mytype(0)
----------------------^
compilation aborted for test.f90 (code 1)

If the main program accesses mytype directly from mymod, the program compiles and executes as expected.

If the main program accesses mytype from wrapper_module, and wrapper module accesses mytype via "use mymod", the program compiles and executes as expected.

If the main program accesses mytype from wrapper_module, and wrapper module accesses mytype via "use mymod,only:mytype" (the example code above), the compilation fails with the above message. I think this is unexpected behavior.

The code compiles and executes as expected when compiled with gfortran 5.x

Thanks,

milan

Environment: Suse linux,

I have a real function tbl that is invoking a fortran function. The function is double precision, the variable catching the return is also double. I have inserted write statements just before the return, and just after the value is caught. The two do NOT match.

dtblu3 is in a utility library that MANY other applications use. tbl is part of an analysis application that mixes C, Fortran, and Oracle's Pro C code.

      real function tbl (a,v,d,ier)

      real a(*),v(*),d(*)
      double precision xi,yi,zi, f3(10000)
      double precision dval, dd, da, xary(100), yary(100), zary(100)

      double precision my_tbl

...

            my_tbl = dtblu3(xi,yi,zi,xary,yary,zary,f3,ndx,ndy,ndz,nx,
     1                  ny,nz,nxa,nya,nza)
      write(*,*) "tbl point 1 my_tbl = ", my_tbl

      double precision function dtblu3( x1, y1, z1, x, y, z, f3,
     +                                  ndx, ndy, ndz, nx, ny,
     +                                  nz, mx, my, mz )

      double precision  x(*), y(*), z(*), f3(mx,my,mz)                             
      double precision  x1, y1, z1, x2, y2, z2, dterp3

...

            dtblu3 = f3(i,j,k)                                                 
      write(*,*) 'dtblu3 point 1 dtblu3 = ', dtblu3
            return

The output from these write statements is

 dtblu3 point 1 dtblu3 =    1.34000003337860
 tbl point 1 my_tbl =  -3.689348814741910E+019

The compile statement for dtblu3.f is:

/ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/bin/intel64/ifort -c  -I../include dtblu3.f

The compile statement for tbl.f is:

/ots/sw/Intel/compilers_and_libraries_2016.1.150/linux/bin/intel64/ifort -g -C -c -assume byterecl -convert big_endian -check -I /boeing/include -I/usr/include -I/net/psn02hom/home/d/dra3556/work/vobs/libutil/dvlp/include tbl.f

So, any ideas on where my problem might be originating?

Hi Folks,
I have an F90 shared object library compiled with the Intel FORTRAN compiler - don't know what version.

I have a C++ driver compiled with the Gnu compiler (v4.4.7) which can link against the fortran library fine.

I'm trying to recompile the fortran library so I can trace through it with a debugger (and eventually to modify it).  I'm using ifort Version 16.0.0.109 Build 20150815.

However, when I attempt to run the driver with the recompiled library, I get an error passing arguments into a subroutine.  The function prototype is as follows:

subroutine set_some_params(Dir, bufSize,Mode, flag1, flag2, param1, param2, param3)
!DEC$ IF DEFINED(_WIN32)
!DEC$ ATTRIBUTES DLLEXPORT, DEFAULT, ALIAS:'set_some_params' :: set_some_params
!DEC$ ELSE
!DEC$ ATTRIBUTES ALIAS:'set_some_params' :: set_some_params
!DEC$ END IF

   implicit none

   character(FILEPATHLEN), intent(in) :: Dir ! directory path
   integer, value :: bufSize                    ! buffer size [5000]
   integer, value :: Mode                       ! run mode
   integer, value :: flag1
   integer, value :: flag2
   real(8), value :: param1
   integer, value :: param2
   integer, value :: param3

...

This is the first call of a fortran library function, and it crashes.  Loading the exe & core file into gdb shows the failure where the bufSize parameter is first used.

Printing the Dir variable in gdb shows the expected value, however the rest of the arguments I get the following:

(gdb) p bufSize
Cannot access memory at address 0x1388
(gdb) p Mode
Cannot access memory at address 0x0
(gdb) p flag1
Cannot access memory at address 0x0
(gdb) p flag2
Cannot access memory at address 0x0

etc.

The ifort compile command looks like this:

/usr/local/bin/ifort -D_LINUX64 -g -c -u -r8 -i4 -fPIC -fpp1 -reentrancy -threads -recursive -fopenmp ../../Source_F/some_file.f90 -o some_file.o

Which produces the following warning:
ifort: command line remark #10128: invalid value '1' for '-fpp'; ignoring

The library link line looks like this:

/usr/local/bin/ifort -D_LINUX64 -V -fPIC -shared --reentrancy -threads -recursive -fopenmp -o ../../../lib_x64/some_lib.dll ./some_file.o ./some_file2.o ./some_file3.o -L. -L/opt/intel/lib/intel64/ -i-dynamic -lifport -lifcore -limf -lsvml -lintlc

I get the following warnings here:
ifort: command line warning #10006: ignoring unknown option '-freentrancy'
ifort: command line remark #10148: option '-i-dynamic' not supported

And the -L path /opt/intel/lib/intel64/ doesn't exist on my system, but it apparently doesn't need anything there.

The C++ command line:

g++ -g -m64 driver.cc -o driver ./DllUtils.o ./DllMainDll.o -ldl -lc -lm

where DllUtils.o and DllMainDll.o are C++ object files that specify some helper functions and interfaces to the shared object library.  Sorry about the "Dll" notation - that's from the original developer.

The header file, DllUtils.h contains the following:

typedef void (STDCALL *fnPtrset_some_params)(char Dir[512], int bufSize, int Mode, int flag1, int flag2, double param1, int param2, int param3);

So to summarize - the original library works fine.  When I attempt to recompile the library using the original makefiles (modified for different path to ifort only) I get an error passing arguments.  First argument (pointer) is OK, the rest fail.

Sorry this is so vague - it's a huge project, I'm trying to extract what may be relevant here.  This is on a CentOS 6 box

I used my email to apply for student version composer for Fortran and successfully received the serial number, when I put in the serial number, it showed authorization failure. I have checked that my serial number is active. Could anybody help me or give me some suggestions? THANKS.