Hi all, after build netcdf 4.4.1, i'm trying to build netcdf-fortran 4.4.4 (netcdf 4.4.1 is ok), with intel parallel studio xe 2016 update3, in rhel Enterprise Server 7.2.

'configure' and 'make' are ok, but 'make check' stops with:

ftst_rengrps.F(49): error #6404: This name does not have a type, and must have an explicit type.   [NF_NETCDF4]
      call check(nf_create(FILE_NAME, NF_NETCDF4, ncid))
--------------------------------------^
compilation aborted for ftst_rengrps.F (code 1)
make[2]: *** [ftst_rengrps.o] Error 1
make[2]: Leaving directory `/root/libs/netcdf-fortran-4.4.4/nf_test'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/root/libs/netcdf-fortran-4.4.4/nf_test'
make: *** [check-recursive] Error 1
^C
[1]+  Exit 2                  make check &>check.log

Asked netcdf-support, and here is the answer:

Hello,

Unfortunately I'm not familiar with intel parallel studio; it clearly looks like a compiler issue, but I don't have an environment where I can try to recreate this problem.

The Intel documentation provides some instructions for compiling netCDF-Fortran, found at the following address:

* https://software.intel.com/en-us/articles/performance-tools-for-software-developers-building-netcdf-with-the-intel-compilers

It may be able to provide some additional information that I lack.

I'm sorry I can't provide a more immediately useful or applicable answer, but hopefully this information will be helpful!

Have a great day,

-Ward

All log files are atthached

I´m stuck at this point and I hope your help make my day ;)

Thanks!!

Hi all,

Recently our university has upgraded from ifort 12 to ifort 15, and now if I compile code with "-mcmodel=medium -shared-intel", it no longer runs on our cluster (though it does if I revert to the ifort 12 compiler).

For example, I created the following simple test file:

program progtest
implicit none

integer i

do i = 1, 10
  print*, i
enddo

end

If I compile it with "ifort -O2 -C progtest.F90 -o progtest" and run it on the cluster, it works. If I compile it with "ifort -O2 -C -mcmodel=medium -shared-intel progtest.F90 -o progtest" then I get the following error:

./progtest: symbol lookup error: ./progtest: undefined symbol: __intel_new_feature_proc_init

Obviously the actual code I need to run is more complicated, hence the need for the mcmodel=medium, but I'm stumped why it doesn't work when compiling with ifort version 15.0.0.

Can anyone offer any help?

Many thanks,

Liam

Hello,

I am facing an issue with Intel 16.0.3.210.

The issue is that when we want to have 1D pointer to a 3D array that is contained into a type, the compiler is reporting that the data target must be simply contiguous or of rank one.

However, when the array is not contain into a type, it does work. The issue is also not present in Intel 15.x or 14.x series.

Any ideas ?

Thank you

program test

  implicit none


 type :: t_con
 real, allocatable :: array(:,:,:)
 end type

 integer, parameter :: N=30
 real, allocatable, target :: a(:,:,:)
 real, pointer :: p(:)
 real, pointer :: p1(:)
 type(t_con), target  :: t_a


 allocate(a(N,N,N))
 allocate(t_a%array(N,N,N))

 a=0.0
 t_a%array = 0.0

 p(1:30) => a(:,:,3)

 p(2) = 500.0

 print *, p(2), a(2,1,3)


 p1(1:30) => t_a%array(:,:,3)

 p1(2) = 200.0
 print *, p1(2), t_a%array(2,1,3)

 nullify(p)
 deallocate(a)
 deallocate(t_a%array)



end program test

Doctor Fortran in "Thirty-Eight"

Dear intel team,

I am part of a larger group of developers that work on a quantum chemistry code  written in Fortran that was founded a few decades ago. We made now an initiative to identify some "hidden bugs" in the code for several reasons. As the code grew over the years people started coding using some Fortran constructs that are considered today as bad practice because they result in side effects that are error prone and hard to debug. In particular, we tried to identify bugs related to uninitialized variables, which I tried to identify with -ftrapuv available in the ifort 15.0.2 compiler for a Linux cluster. Old parts of the code, however, frequently employ variables with the SAVE attribute. There are several subroutines where those variables are initialized if a certain flag is given and incremented by some value otherwise. In the latter, the compiler is not  able to identify that initialization was correctly performed in an previous (initial) subroutine call. Unfortunately, there are too many variables with the SAVE attribute to simply change the code. There is another social aspect that some members of the community refuse such a re-writing. Is there a solution to that problem or any plans to provide a mechanism to detect uninitialized save variables. When using the gfortran compiler with the -fnit-(real/integer/logical)=something_silly flag the program does not abort when variables with save attributes are accessed.

Kind regards,

Ben

I compiled this code with ifort 17.0 and it gives segfault.

https://gist.github.com/appleparan/be9eb47be87f5440c8008118492b4f10

It works with gfortran 6.2 but ifort fails. Is this ifort's bug?

This is traceback

#0  0x0000003a06a7a96c in free () from /lib64/libc.so.6
#1  0x0000000000563e7b in for_dealloc_allocatable ()
#2  0x00000000004057ca in MAIN__ ()
#3  0x0000000000403ade in main ()
#4  0x0000003a06a1ecdd in __libc_start_main () from /lib64/libc.so.6
#5  0x0000000000403969 in _start ()

gnu libc version status

ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

ifort version status

ifort (IFORT) 17.0.0 20160721
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

FFTW version 3.3.5 compiled with --enable-avx --enable-openmp

I have this issue with ifort 12.1 as well as 17.0

I upgraded my Intel C++ and Fortran compilers last week (September 26-30, 2016) to the Intel 17 versions 17.0.0 and immediately ran into what appears to be a compiler bug due to improper inlining of code. My  code did not have this problem with 16.0.3, which I had previously been using. I have not yet been able to get a simple reproducer, so I can only supply the symptoms. My code fails in what appears to be a two or three level inlined code. When it tries to do a sufficiently deep inline expansion I get a run time segmentation violation. The author of this section of the code (which is a huge multideveloper project) is trying to do very aggressive inlining, and this same code has been used intensively since Intel version 15. I experimented with different compilation options and discovered that using the arguments "-no-ip -fno-inline" to replace the argument "-ip" for ifort enables my code to again run properly. I tracked down the location of the offending subroutine, which was quite simply a single loop and when I removed this as a sub-subroutine (i.e. a contains routine inside another subroutine) and simply added the loop to replace the original call, then the code will also again run. This is the basis for my suspicion that the problem is with the compiler doing something wrong when it tries to inline this code. My only guess is that some memory access was messed up by the inlining, perhaps a stack overflow. If I can create a simple reproducer I will supply it to this forum, but for now I just wanted to get this bug documented somewhere.

All,

I'm hoping you can help with this. I just tried this simple program:

program test
   implicit none

   integer :: estat, cstat
   character(len=255) :: cmsg

   estat = -999
   cstat = -999
   cmsg  = "notfilled"

   call execute_command_line("/bin/cp ~/yayay ~/alskalkd", &
      exitstat=estat, cmdstat=cstat, cmdmsg=cmsg)
   write (*,*) 'estat: ', estat
   write (*,*) 'cstat: ', cstat
   write (*,*) "cmsg:  ", trim(cmsg)

end program test

Nothing too fancy or anything. I do not have a file called "yayay" in my home, so I expected to see cmdmsg to have something and yet:

(276) $ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.0.098 Build 20160721
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

(277) $ ifort test.F90 && ./a.out
/bin/cp: cannot stat ‘/home/mathomp4/yayay’: No such file or directory
 estat:            1
 cstat:            0
 cmsg:  notfilled

So, we see that cp failed (as it should) but cmdmsg was never changed. I suppose I'm wondering, given the standard:

CMDMSG (optional) shall be a default character scalar. It is an INTENT (INOUT) argument. If an error condi-
tion occurs, it is assigned a processor-dependent explanatory message. Otherwise, it is unchanged.

have I encountered the dreaded "processor-dependent" result of nothing? EXITSTAT seems to have been set to non-zero (which is the return status of the cp call), but...no cmdmsg.

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

Hello,

I have run some tests using the trial version of the Intel Parallel Studio XE 2017 and I am considering purchasing a licence.

However, before I do I have a few questions relating to which edition I should purchase.

I suspect that the Composer Edition is all that I will require, but I noticed that the Processional Edition has the following extra components, Intel Advisor, Intel Inspector and Intel Vtune Amplifier XE3. 

Can you confirm that confirm that with the Composer Edition I can still use optimatization flags like -xCORE_AVX2 and -ipo, as I have used these options in my testing.

Thanks,

Simon

Dear all,

I have the following type variable:

  TYPE::tMACROCELLNODE
   INTEGER                                        :: nElem
   INTEGER                                        :: AA
   INTEGER                                        :: IDnode
   INTEGER                                        :: IDmCell
   REAL(KIND=8),ALLOCATABLE,DIMENSION(:)          :: WFX
   REAL(KIND=8),ALLOCATABLE,DIMENSION(:)          :: WFY
   !
   REAL(KIND=8),ALLOCATABLE,DIMENSION(:)          :: WFtime
   REAL(KIND=8),ALLOCATABLE,DIMENSION(:)          :: WFpdf
   !
   REAL                                           :: qs
  ENDTYPE

During my program, I allocate it as:

first of all:

ALLOCATE(MACROCELLNODE(npairs))

and then

DO i.....

       ALLOCATE(MACROCELLNODE(i)%WFX(n))
...
...

My question is:

Is it possible deallocate only one field of it?

for example:

i=10
DEALLOCATE(MACRCELLNODE(i)%WFX(:))

Thank to all of you

Diego

Hi, i tried to install parallel studio xe 2016 (file is l_mpi_p_5.1.3.223) for fortran compiler to linux opensuse .  I installed it by install.sh then i sourced it to .bashrc as "source /opt/intel/compilers_and_libraries_2016/linux/bin/compilervars.sh intel64" but ifort doesnt work.

when i try :

/opt/intel/compilers_and_libraries_2016/linux/bin # ./compilervars.sh

the error is :

"compilervars.sh [-arch] <arch> [-platform <platform>]

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

If the arguments to the sourced script are ignored (consult docs
for your shell) the alternative way to specify target is environment
variables COMPILERVARS_ARCHITECTURE to pass <arch> to the script
and COMPILERVARS_PLATFORM to pass <platform>
./compilervars.sh: line 73: return: can only `return' from a function or sourced script

ERROR: architecture is not defined. Accepted values: ia32, intel64, mic"

what should i do? help me please!

There is no architecture file as intel 64 at " /opt/intel/compilers_and_libraries_2016/linux/bin" folder.

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