I'm trying to compile and run wrf model 3.8.1 with compiler intel parallel studio xe 2016 update3, in rhel Enterprise Server 7.2. The processors are Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz.

Following this url:

https://software.intel.com/en-us/articles/how-to-get-wrf-running-on-the-intelr-xeon-phitm-coprocessor

All compilation modules ends ok, but when run wrf.exe, it stops with this message:

rank 9 in job 11  master_33806   caused collective abort of all ranks
  exit status of rank 9: killed by signal 9
rank 4 in job 11  master_33806   caused collective abort of all ranks
  exit status of rank 4: killed by signal 9
rank 3 in job 11  master_33806   caused collective abort of all ranks
  exit status of rank 3: killed by signal 9
rank 2 in job 11  master_33806   caused collective abort of all ranks
  exit status of rank 2: killed by signal 9

And the file rsl.error.0000 is:

taskid: 0 hostname: master
 module_io_quilt_old.F        2931 F
 MPASPECT: UNABLE TO GENERATE PROCESSOR MESH.  STOPPING.
  PROCMIN_M            1
  PROCMIN_N            1
  P                   -7
  MINM                 1
  MINN                -7
-------------- FATAL CALLED ---------------
FATAL CALLED FROM FILE:  module_dm.b  LINE:     155
module_dm: mpaspect
-------------------------------------------
application called MPI_Abort(MPI_COMM_WORLD, 1) - process 0

Previously, I test configre wrf with option 20 (dmpar) INTEL (ifort/icc): Xeon (SNB with AVX mods), with same results... (same error in wrf.exe)

Thanks in advance

Both http://fortranwiki.org/fortran/show/Typed+enumerators and http://docs.cray.com/books/S-3693-36/html-S-3693-36/z1018297010.html show an example of a named enum in Fortran with ISO_C_BINDING.

I cannot build this with Intel 17 or GCC 6.2.  Can you please help me understand what I am doing wrong?

! enum.F
      module enumtest
      use iso_c_binding
#if NAMED_ENUM
      enum, bind(c) :: color
        enumerator :: red = 4, blue = 9
        enumerator yellow
      end enum
#else
      enum, bind(c)
        enumerator :: red = 4, blue = 9
        enumerator yellow
      end enum
#endif
      end module enumtest

$ ifort -std08 -free -g -warn all -traceback -c enum.F
$ ifort -std08 -free -g -warn all -traceback -DNAMED_ENUM -c enum.F
enum.F(4): error #5082: Syntax error, found '::' when expecting one of: <END-OF-STATEMENT> ;
      enum, bind(c) :: color
--------------------^
enum.F(5): error #6163: This statement is not in the correct order.
        enumerator :: red = 4, blue = 9
--------^
enum.F(6): error #6163: This statement is not in the correct order.
        enumerator yellow
--------^
enum.F(7): error #8131: An END ENUM statement occurred without a corresponding ENUM statement.
      end enum
------^
compilation aborted for enum.F (code 1)

$ gfortran-6 -std=f2008 -c enum.F
$ gfortran-6 -std=f2008 -DNAMED_ENUM -c enum.F
enum.F:4:6:

       enum, bind(c) :: color
      1
Error: Unclassifiable statement at (1)
enum.F:5:22:

         enumerator :: red = 4, blue = 9
                      1
Error: ENUM definition statement expected before (1)
enum.F:6:18:

         enumerator yellow
                  1
Error: ENUM definition statement expected before (1)
enum.F:7:9:

       end enum
         1
Error: Expecting END MODULE statement at (1)

Here is the code:

program main
	implicit none
	character(:), allocatable :: i
	write(*,*)["1","1"//"2"]
	i="2"
	write(*,*)["1","1"//i]
end program

I expect this two write will give the same results. But the first one gives ["1 ","12"] while the second one truncate "1"//i to "1". I know this may due to the fact that at compile time compiler can not estimate the length of "1"//i so it make the length with the longest length it can measure (which is one in this case). I think this is quite unexpected and compiler should warn about it or just raise an error.

dear all,

I have the following problem. I Have to read a binary file written in single precision:

  OPEN(1,file=input_rain_file,STATUS='old', form='BINARY')

 !TEMP A SINGLE PRECISION VARIABLE

  DO i=1,nmacro
     READ(1) TEMP(:,i)       ! in [mm], single precision
  END DO

and then I apply

DOUBLEP = TEMP

I do not know if this is formally correct and if I can directly read the single precision file using a variable in double precision.

Thanks in advance for any help

Diego 

I have an issue with the double complex data type and the Fortran compiler.

When I compare several basic operations on Windows and Linux, the results are not identical (differences arise from division and are visible at 14th to 15th digit). When doing the same operations with double precision (omitting the complex part) the results are identical up to the last digit on both platforms. Even LAPACK zgesv and MKL zgesv produce different results for the identical input (using dgesv, the results are identical).

The problem seems only for Linux: The basic operations may also be replaced by double precision operations for the real and imaginary parts of a complex number. This produces bit identical results on both platforms, where Windows double complex and its replacement by double precision arithmetics are identical.

Is there a way to enforce ifort to produce the same results for double complex on Linux, since this is very important for reproducibility across platforms?

If not, do you know the reason for the differences of double complex arithmetics on Linux?

Thanks for your answer in advance,
   
Tom

Trying to compile the following code with Intel Fortran Composer 17.0.0 results in a catastrophic internal compiler error.

module nrtype
    use iso_fortran_env
    implicit none

    integer, parameter :: itp = int8 ! Define quarter precision integer(1 bytes).
    integer, parameter :: ihp = int16! Define  half   precision integer(2 bytes).
    integer, parameter :: isp = int32! Define single  precision integer(4 bytes).
    integer, parameter :: idp = int64! Define double  precision integer(8 bytes)

    integer, parameter :: rsp = real32  ! Define single precision real ( 4 bytes). 7.22 decimal digits
    integer, parameter :: rdp = real64  ! Define double precision real ( 8 bytes). 14.95 decimal digits
    integer, parameter :: rqp = real128 ! Define quad   precision real (16 bytes). 34.02 decimal digits
end module nrtype

module modMesh
    use nrtype
    implicit none

    type DOFType(nEQs)
        integer(isp), len :: nEQs
        real(rdp) :: x
        real(rdp), dimension(nEQs) :: u, f, r
        real(rdp), dimension(nEQs,nEQs) :: fluxJac
    end type DOFType

    type cellType(nDOFs, nEQs)
        integer(isp), len :: nDOFs
        integer(isp), len :: nEQs
        integer(isp), dimension(2) :: idFace
        integer(isp), dimension(2) :: idNb
        type( DOFType(nEQs) ), dimension(nDOFs) :: DOF
    end type cellType

    type faceType(nDOFs, nEQs)
        integer(isp), len :: nDOFs
        integer(isp), len :: nEQs
        real(rdp) :: x
        integer(isp), dimension(2) :: idNb
        type( cellType(nDOFs, nEQs) ), pointer :: nbL, nbR
    end type faceType

    type meshType(nCells, nGhosts, nDOFs, nEQs)
        integer(isp), len :: nCells
        integer(isp), len :: nGhosts
        integer(isp), len :: nDOFs
        integer(isp), len :: nEQs

        integer(isp) :: nFaces

        type( faceType(nDOFs, nEQs) ), dimension(1-nGhosts:nCells+nGhosts) :: faceList
        type( cellType(nDOFs, nEQs) ), dimension(1-nGhosts:nCells+nGhosts) :: cellList
    end type meshType

    type( meshType(nCells=:, nGhosts=:, nDOFs=:, nEQs=:) ), target, allocatable :: mesh
end module modMesh

program test
    use nrtype
    use modMesh

    allocate ( meshType(5,5,1,1) :: mesh )

    mesh%cellList(-4)%DOF(1)%u(1) = 1.0

end program test

Replacing lines 50 and 51 for

        type( faceType(nDOFs, nEQs) ), dimension(-nGhosts:nCells+nGhosts) :: faceList
        type( cellType(nDOFs, nEQs) ), dimension(-nGhosts:nCells+nGhosts) :: cellList

prevents the compiler error but causes a segfault during execution.

I am working with some fortran code that provides valid results when we compiler with -fpe0 -no-vec, if fails if we use -ftz -no-vec though. 

The only difference I can see between -ftz and -fpe0 regarding floating point behavior is that both flush denormals to zero on SIMD registers while only -fpe0 also flushes denormals to zero in the x87 instructions.    We don't believe there should be any x87 instructions in the code.  The current compiler option is -xCORE-AVX2  -no-vec and either -ftz or -fpe0.   This is with the Intel 16.0 compilers (16.0.4); Linux of course.   Is there a way to turn off x87 code generation so everything is done in the SIMD execution units (even if it is just scalar mode)?  

fpe0 causes code to abort when an exception occurs, while -ftz will let us go along happily calculation nans and infinities, but if everything is done in the SIMD registers what floating point values will behave differently?

David M

I am having a memory issue using RESHAPE in Fortran 90. The program faults when -openmp is used, but only for relatively large arrays--I've chosen 1000x1000 as an example. The program runs fine if RESHAPE is not called, with or without -openmp. I have two questions:

1) Why does this happen? 

2) Why does the traceback not point to the line with RESHAPE? Usually the traceback feature is pretty good at pinpointing the line.

main.f90:

<pre class="brush:fortran">

program main

   integer, parameter :: REAL_KIND = 8

   integer, parameter :: n1 = 1000

   integer, parameter :: n2 = 1000

   real(kind=REAL_KIND) :: x(n1*n2)

   real(kind=REAL_KIND) :: xx(n1,n2)

   print *, 'Before RESHAPE in main'

   x = 0.0

   xx= reshape(xx,(/n1,n2/))

   print *, 'Success in main'

end program main

</pre>

************** 

Scenario 1:

>> ifort -O0 -xHost -traceback -check bounds -check uninit -r8 -implicitnone -c main.f90

>> ifort -O0 -xHost -traceback -check bounds -check uninit -r8 -implicitnone -o exec main.o

>> ./exec

Before RESHAPE in main

Success in main 

************** 

Scenario 2: 

>> ifort -O0 -xHost -traceback -check bounds -check uninit -r8 -implicitnone -openmp -c main.f90 

>> ifort -O0 -xHost -traceback -check bounds -check uninit -r8 -implicitnone -openmp -o exec main.o 

>> ./exec 

forrtl: severe (174): SIGSEGV, segmentation fault occurred

Image              PC                Routine            Line        Source             

exec               000000000047AB85  Unknown               Unknown  Unknown

exec               0000000000478947  Unknown               Unknown  Unknown

exec               0000000000448244  Unknown               Unknown  Unknown

exec               0000000000448056  Unknown               Unknown  Unknown

exec               00000000004271F9  Unknown               Unknown  Unknown

exec               0000000000403820  Unknown               Unknown  Unknown

libpthread.so.0    0000003E5FA0F710  Unknown               Unknown  Unknown

exec               00000000004033CB  MAIN__                      1  main.f90

exec               00000000004033AE  Unknown               Unknown  Unknown

libc.so.6          0000003E5EE1ED5D  Unknown               Unknown  Unknown

exec               0000000000403239  Unknown               Unknown  Unknown

************ 

Note: 

>> ifort --version

ifort (IFORT) 16.0.0 20150815 

Hi,

I'm not sure if this is the right place to ask this kind of help.. but I really don't know how and what else to do..

Forgive me if I say something stupid, that's because I have no previous programming knowledge at all.

I need to type a fortran program, but installation is not working for me.

I downloaded this: parallel_studio_xe_2017_setup, and Visual Studio community 2015.

During the installation, (as you can see on pictures 01 to 03), there were a few "pre-requisite issues summary" I should have installed before (or could install after, I guess. I don't know!)

I opened visual studio and a project that i have, but after build solution.. it failed. (picture 04)

I wrote a "INCLUDE 'link_fnl_shared.h'" but i know something is missing.. 

I guess its because the "pre-requisite issues summary" i didn't installed before. But the big (stupid, i know) problem is that I don't know how to install it. I'm trying to read all this 'release notes' the site says about, but is not helping.. because I really have none knowledge to deal with that.

Anyways.. just know i found how to install "x64 compiler and tools", one of the requisite.. but I have the erros still.

Can anyone.. try.. maybe.. hopefully.. help me?

Thanks and sorry for that.

Gabriela

Hello All, I have been facing and issue with respect to Intel Fortran complier while compiling a program called TIEGCM. Which is an open source application.

/opt/intel17/compilers_and_libraries_2017.0.098/linux/mpi/intel64/bin/mpif90 -fc=ifort -r8 -heap-arrays -I. -I/opt/tiegcm2.0/tiegcm_trunk/src -I/usr/local/netcdf-4.1.3/include -I/opt/esmf/esmf/DEFAULTINSTALLDIR/mod/modO/Linux.intel.64.mpiuni.default -I/opt/esmf/esmf/DEFAULTINSTALLDIR/include  -O3  -DLINUX  -DMPI  -c -o output.o /opt/tiegcm2.0/tiegcm_trunk/src/output.F
ifort: command line remark #10411: option '-openmp' is deprecated and will be removed in a future release. Please use the replacement option '-qopenmp'
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(437): error #6633: The type of the actual argument differs from the type of the dummy argument.   [RHO]
     |  diags(ix)%units,rho,diags(ix)%levels,lev0,lev1,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(459): error #6633: The type of the actual argument differs from the type of the dummy argument.   [QJI_TN]
     |  diags(ix)%units,qji_tn(lev0:lev1-1,lon0:lon1),diags(ix)%levels,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(494): error #6633: The type of the actual argument differs from the type of the dummy argument.   [TEC]
     |  diags(ix)%units,tec(:),'lon',lon0,lon1,'lat',lat,lat,0)
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(520): error #6633: The type of the actual argument differs from the type of the dummy argument.   [UI]
     |    diags(ix)%units, ui(:,:,lat),diags(ix)%levels,
---------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(548): error #6633: The type of the actual argument differs from the type of the dummy argument.   [VI]
     |    diags(ix)%units, vi(:,:,lat),diags(ix)%levels,
---------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(576): error #6633: The type of the actual argument differs from the type of the dummy argument.   [WI]
     |    diags(ix)%units, wi(:,:,lat),diags(ix)%levels,
---------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(599): error #6633: The type of the actual argument differs from the type of the dummy argument.   [TOTAL_HEAT]
     |  diags(ix)%units,total_heat(lev0:lev1-1,:),diags(ix)%levels,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(621): error #6633: The type of the actual argument differs from the type of the dummy argument.   [CO2_COOL]
     |  diags(ix)%units,co2_cool,diags(ix)%levels,lev0,lev1,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(643): error #6633: The type of the actual argument differs from the type of the dummy argument.   [NO_COOL]
     |  diags(ix)%units,no_cool,diags(ix)%levels,lev0,lev1,
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(666): error #6633: The type of the actual argument differs from the type of the dummy argument.   [SIGMAPED]
     |  diags(ix)%units,sigmaped(lev0:lev1-1,lon0:lon1),
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(689): error #6633: The type of the actual argument differs from the type of the dummy argument.   [SIGMAHAL]
     |  diags(ix)%units,sigmahal(lev0:lev1-1,lon0:lon1),
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(711): error #6633: The type of the actual argument differs from the type of the dummy argument.   [LAMDAPED]
     |  diags(ix)%units,lamdaped(lev0:lev1-1,lon0:lon1),
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(733): error #6633: The type of the actual argument differs from the type of the dummy argument.   [LAMDAHAL]
     |  diags(ix)%units,lamdahal(lev0:lev1-1,lon0:lon1),
------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(759): error #6633: The type of the actual argument differs from the type of the dummy argument.
     |    diags(iex)%units,exyz*100.,diags(iex)%levels,lev0,lev1,'lon',
-------------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(763): error #6633: The type of the actual argument differs from the type of the dummy argument.
     |    diags(iey)%units,exyz*100.,diags(iey)%levels,lev0,lev1,'lon',
-------------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(767): error #6633: The type of the actual argument differs from the type of the dummy argument.
     |    diags(iez)%units,exyz*100.,diags(iez)%levels,lev0,lev1,'lon',
-------------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(792): error #6633: The type of the actual argument differs from the type of the dummy argument.   [BXYZ]
     |    diags(ibx)%units,bxyz,'lon',lon0,lon1,'lat',lat,lat,0)
---------------------------^
/opt/tiegcm2.0/tiegcm_trunk/src/diags.F(795): error #6633: The type of the actual argument differs from the type of the dummy argument.   [BXYZ]
     |    diags(iby)%units,bxyz,'lon',lon0,lon1,'lat',lat,lat,0)

It goes on ...

Kindly Help !!

I

We have been using an old version of the Intel Fortran Compiler, Professional Edition 11.1 for Linux,  on Ubuntu 12.04LTS installed on a Xeon CPU with an Intel server since 2011.   Now we have upgraded our server to a E5-2600 V4 Xeon based Intel server and installed Ubuntu 16.04LTS with Fortran Intel Parallel Studio XE Composer Edition for Fortran, for Linix version 17.0.

Our problem is that when we recompile our Fortran code on the new server with the new compiler  (17.1) it runs drastically slower compared to when we run the older statically linked executable (compiled on the old server using Fortran 11.1).  The old executable runs 20% faster on the new server which is the speed improvement we excepted due to the  hardware upgrade.  However, that speed improvement is completely lost if we recompile our code with the new 17.1 compiler on the new server.

We have tried optimization levels 01 and 03 but they don't help performance.  

Any suggestions would be helpful.   

Are there older versions of the compiler we can try and if yes where can we download them?

Thank you,

Peter Sangas

Compiler Versions: 15.0.2, 17.0.0

OS: RHEL 6.8

Kernel: 2.6.32-642.4.2 64-bit

Compile lines:

Works fine:    ifort -O3 -o test1 mopen.F
Gives wierd results: ifort -check all -o test2 mopen.F

The test1 and test2 executables produce two completely different results.

The following code produces this error:

        program htemp
        use ifposix
        implicit none
        integer(8) islen
        character*16 myfile
        integer(4) lename,ipxflag,ipxmode,ipxfd,ipxerr,ipxlen4
        integer(4) :: jstat_h
        integer(8) :: ipxlen

! open the signal
        myfile="mopen.F"
        write(6,*)  'opening ',myfile
        ipxflag=IPXFCONST('O_RDONLY')
        ipxmode=0
        lename=len_trim(myfile)
        call PXFOPEN(myfile,lename,ipxflag,ipxmode,ipxfd,ipxerr)
        write(6,*)  'PXFOPEN returned ',ipxfd
        if(ipxerr.gt.0) stop

        call pxfstructcreate('stat',jstat_h,ipxerr) ! create stat structure
        call pxffstat(ipxfd,jstat_h,ipxerr)
        call pxfint8get(jstat_h,'st_size',ipxlen,ipxerr)
        write(6,*)  'pxfint8get returned st_size ',ipxlen
        call pxfintget(jstat_h,'st_size',ipxlen4,ipxerr)
        write(6,*)  'pxfintget  returned st_size ',ipxlen4

        call pxfstat(myfile,lename,jstat_h,ipxerr)
        call pxfint8get(jstat_h,'st_size',ipxlen,ipxerr)
        write(6,*)  'pxfint8get returned st_size ',ipxlen
        call pxfintget(jstat_h,'st_size',ipxlen4,ipxerr)
        write(6,*)  'pxfintget  returned st_size ',ipxlen4

        INQUIRE(file=myfile,size=islen)
        write(6,*)  'INQUIRE    returned         ',islen
        call pxfstructfree(jstat_h,ipxerr)
        contains


        end program htemp

Minor quirk with the Eclipse integration. I ported a Fortran solution from Windows to a Linux Eclipse workspace. The source files on the Windows side had a mixture of file names ending with .f90 and .F90. I am aware that the extension on the Linux side is case sensitive where the .F90 implies preprocess the file. The Windows Solution use (required) preprocessing. On the Eclipse side, I also checked the preprocess file. Now for the quirk...

The files ending with .F90 were not recognized as Fortran files, and thus make was selected to build, and had no build rule for .F90 files. By renaming the file(s) to have .f90 extensions, build would select ifort, and the build would succeed.

A second (lesser) quirk is the icon to the left of the files under src folder show .c (as opposed to an expected .f).

While I understand that Eclipse integration is not the responsibility of Intel, others here may forward this information on to those who can take action on this.

Jim Dempsey

Any update by chance on the feature request in this post? https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/270668

A quick recap: internal run-time library errors (such as invalid I/O namelist reads, array indexing out-of-bounds, and other "internal" problems) will print a useful stack trace and terminate program execution.  It would be helpful if one could either register a callback which could be executed prior to the exit() call, or raising a signal which could have a user-defined handler registered with the kernel.  This would allow graceful shutdown of things like child-processes or sockets.  I understand the signal-raising method could be difficult since it could leave the RTL in an undefined state if the user tries to do other library-involved operations as part of their handler function.

If the feature hasn't made its way in yet, is there a library-provided function which we can write and link-in an alternative to (with an equivalent prototype) to override the RTL's internal error termination function?

Thanks in advance

Tuesday, October 18, 2016 - 9:00-10:00AM PT

We will describe, with C and Fortran examples, new opportunities for performance-enhancing vectorization provided by the Intel® AVX-512 instruction set on the processor code named Knights Landing. After an introduction, this will include vectorization of loops that compress or expand arrays; histogram loops; and loops with array of structures accesses. Small sample codes will be available for download.

Please go to the webinar page to register under Vectorization, the “Other” Parallelism You Need.

Hi,

I am trying to get an atomic read out of a global module variable to be returned by the function. A small example is:

integer(c_int) function get_mag(mag) bind(C, name="get_mag")
#ifdef DLL
!DEC$ ATTRIBUTES DLLEXPORT :: get_mag
#endif
use VOL, only: x_g, y_g

implicit none
real(c_double), intent(inout) :: mag
doubleprecision :: x, y
integer :: num

num = 1
!$omp atomic read
x=x_g(num)
!$omp atomic read
y=y_g(num)
mag=hypot(x, y)

get_mag=0
end function get_mag

I get an error "error #8550: An OpenMP* ATOMIC capture-statement is expected" on both atomic reads. I don't know what I'm doing wrong. 

Module VOL has simply:

double precision ::  x_g(10000), y_g(10000) 

I have the ifort version "Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 16.0.2.181 Build 20160204"

Thanks in advance

I am seeing a segmentation fault with the code below. I have two questions:

1) Why does Test 1 pass but Test 3 fail? In other words, if the same operation on the RHS of the assignment operator '=' is being conducted, what difference does it make if we assign the result to a local variable or to the component of a derived type?

2) Why does Test 2 pass but Test 3 fail? In other words, why does it make a difference if we multiply by a local variable or a component of a derived type, if they are simply scalars?

Below are the source code, compilation commands, and runtime result. Thank you in advance!

program main

   type someType
      real(8) :: scalar
      real(8), allocatable :: array(:,:)
   end type someType

   integer, parameter :: n1 = 2000
   integer, parameter :: n2 = 2000
   type(someType) :: obj
   real(8) :: scalar
   real(8), allocatable :: array(:,:)

   ! Set up arrays and scalars
   scalar = 1.0d0
   obj%scalar = 1.0d0
   allocate(array(n1,n2))
   allocate(obj%array(n1,n2))

   ! Do tests
   array = obj%array*obj%scalar
   print *, 'Test 1 successful.'
   obj%array = obj%array*scalar
   print *, 'Test 2 successful.'
   obj%array = obj%array*obj%scalar
   print *, 'Test 3 successful.'

end program main

>> ifort --version
ifort (IFORT) 16.0.0 20150815>> make
ifort -O0 -xHost  -traceback -check bounds -check uninit  -r8 -implicitnone  -c main.f90
ifort -O0 -xHost  -traceback -check bounds -check uninit  -r8 -implicitnone  -o exec main.o>> ./exec
 Test 1 successful.
 Test 2 successful.
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
exec               0000000000478E65  Unknown               Unknown  Unknown
exec               0000000000476C27  Unknown               Unknown  Unknown
exec               000000000042A204  Unknown               Unknown  Unknown
exec               000000000042A016  Unknown               Unknown  Unknown
exec               0000000000406266  Unknown               Unknown  Unknown
exec               0000000000409880  Unknown               Unknown  Unknown
libpthread.so.0    0000003E5FA0F710  Unknown               Unknown  Unknown
exec               0000000000404A70  MAIN__                     25  main.f90
exec               0000000000402F7E  Unknown               Unknown  Unknown
libc.so.6          0000003E5EE1ED5D  Unknown               Unknown  Unknown
exec               0000000000402E09  Unknown               Unknown  Unknown

Hi,

I installed intel fortran in my MacBook after installing X-code, however, the fortran option is not seen when starting X-code so I could not locate or use the fortran compiler. Can someone please help?

Dear FORTRAN experts,

I was recently promoted Code Custodian for a Fortran Linux program. Users would like to increase code flexibility, i.e. to use their own functions for some operations.

I suggested we could use shared libraries, which could be changed depending on the user needs, and compiled separately from the main code. However, we have then a problem of quality assurance. How can we trace in the code output files which shared library was used for a code execution ? I know that we could use an external script that would calculate the library's checksum (SHA or MD5, doesn't really matter), but it means an external script layer. Another possibility would be to rely on the library to print its own identity, but my users are sometimes a bit lazy, and the tend to keep existing code lines as long as they can (I do the same, therefore I can understand).

Is it possible from within a Fortran program to identify in a unique manner a shared library dynamically linked at the execution ? Using a checksum or any kind of function signature ? I have an Intel Composer XE 2015 compiler (and a strong headache).

Thank you for your help,

Felix

Bottom line: I'm having problems getting a program to compile under Intel 16 Fortran and I suspect it isn't the code being flagged but is something elsewhere or compiler options.

I'm having problems getting Intel Fortran 16 to compile a rather large, proprietary program, so I can't post more than small snippets of code.This program compiles at least back to Intel Fortran 11, and probably further. The problems don't make sense, so I am wondering if the error messages are red-herrings and there actually is a different issue.

First output error messages:

        ifort -c -qopenmp -fpp -O2 -traceback -g -shared-intel -heap-arrays -fpe3 -qopt-report0 -DMKL -DMKL -DMKL -DMKL -DTHREADEDINTELMKL -I/p/home/apps/intel/compilers/16/compilers_and_libraries_2016.4.258/linux/mkl/include/intel64/lp64 -i4 -r8 -qopenmp -I. -I.. -I.././<directory name> -I.././<directory name> <file name>.f90
<file name>.f90(1235): error #6681: This is either an invalid statement, a declaration statement that is ordered incorrectly, or a null procedure statement.
contains
^
<file name>.f90(1252): error #6681: This is either an invalid statement, a declaration statement that is ordered incorrectly, or a null procedure statement.
end subroutine
^

Like I said, this compiles fine under previous versions, so the error doesn't make sense. I inserted an "endif" or an "enddo" before the "contains" to see if somehow it thought there was an unterminated block, but both of those were correctly flagged by the compiler as unpaired.

Later error messages in the contained subroutines include messages flagging local variable names in the contained routines. In the example below, i is locally declared within the subroutine.

<file name>.f90(3264): error #6405: The same named entity from different modules and/or program units cannot be referenced.   [I]
         do i = 1, size(<array name>,1)
------------^

Anyone have any ideas? I spent several hours reworking code in what that looked to correct to last fall, and never got through all of the issues. (The one above was solved by turning the contained subroutines into not-contained ones, but then there were further issues, including OpenMP related ones.)