Hello.

Is their a possibility to handle F77 fixed format FORTRAN-files and F90 free format FORTRAN-files with an option automatically or have I insert manually the -free option?

Thanks in Advance.

Regards
Cetin

I've stumbled across a very interesting side-effect of the optimizer when compiling between -O0 and -O2 (there are some other flags, which I'll get to below).  First, my code:

REAL*4 X1, X2, Y1, Y2
REAL*8 COORD
X1 = -321.90371704101562500
X2 = -225.23478698730468750
Y1 = -559.80267333984375000
Y2 = -714.07904052734375000

COORD = SQRT((X1-X2)**2+(Y1-Y2)**2)

The interesting result is that you get higher precision in the optimized version of code.  The optimized version gets 182.06065368652344, and the non-optimized version gets 182.06063842773438 (a difference of 1.5e-5).  A closer examination of the generated assembler shows that in the optimized version, the operands are subtracted, squared, and added all in the floating point registers, and then the "fsqrt st0" instruction is executed directly.  However, in the non-optimized version, the intermediate values are computed, but then the resulting intermediate value is stored in a 32-bit register with "fstp dword ptr [esp], st0", and the "__bwr_sqrtf" function is called to perform the actual SQRT (apparently, after first checking to ensure the operand is positive).  So with the optimized version you get the full precision of the FP registers for the intermediate, but in the non-optimized version the intermediate is cast to a single precision float prior to the fsqrt instruction.  We're seeing it as a difference in our case because it appears as though the intermediate is large enough (33146.0795...) to lose enough precision in the cast.  It appears as though the result of the SQRT(X) is cast to a single-precision float prior to being stored in double-precision COORD in both cases.

I understand the Fortran manual states that the result of SQRT(X) is the same type as X, but the generated assembler seems to be contrary to the -fltconsistency argument in that the intermediate is being [inconsistently] cast to a single precision value prior to calling fsqrt.

Our optimized compile flags are:

-extend-source 132 -assume nobscc -align dcommons -sox -fpe0 -fp-stack-check -march=corei7 -fimf-arch-consistency=true -fimf-precision=high -no-fma -prec-div -fp-port -fp-speculation=strict -prec-sqrt -fltconsistency -O2 -m32

Our non-optimized compile flags are:

-extend-source 132 -assume nobscc -align dcommons -sox -fpe0 -fp-stack-check -march=corei7 -fimf-arch-consistency=true -fimf-precision=high -no-fma -prec-div -fp-port -fp-speculation=strict -prec-sqrt -fltconsistency -g -debug full -debug-parameters -check bounds -gdwarf-2 -O0 -m32

I have an old Intel Fortran Compiler that is no longer supported (v 10 Standard on DVD) but works fine for maintaining some legacy codes that I still occasionally use.  I'd like to move it to a new Mac running OS 10.12 (Sierra), but the installer (Intel Software Setup Assistant) stalls after launching and I cannot complete the installation.

This is not uncommon and I have run into the same problem with some Adobe Creative Suite software, and some Garmin mapping software.  There is usually a work around, a command line (Terminal) install from a DVD.  And it's usually one line.  It could take me a long time to sort this out, and I don't really want to buy a new compiler just to get support when the one I have is adequate (my codes are all Fortran 77/90).  So I'd appreciate any help if there is some retired Intel support guru out there with nothing better to do!

Thanks, Harry

Hello all,

the following code is in my opinion wrongly rejected:

  print *,              [ integer :: ], 1    ! OK
  print *, [ integer :: [ integer :: ], 1 ]  ! Fail
end

% ifort bug.f90 -stand f08
bug.f90(2): error #7203: An ac-value-list of an array-constructor must contain at least one ac-value.
  print *, [ integer :: [ integer :: ], 1 ]  ! Fail
--------------------------^
compilation aborted for bug.f90 (code 1)

The code is accepted by the Cray compiler.

Hello,

When I try to compile the program using ifort compilers, following error message is shown:

byte_order is LITTLE_ENDIAN

/opt/intel/bin/ifort -c  -O3 bfrini.f
bufrlib.prm(1): error #5149: Illegal character in statement label field  [/]
/* Copyright (C) 1991-2012 Free Software Foundation, Inc.
^
bufrlib.prm(1): error #5149: Illegal character in statement label field  [*]
/* Copyright (C) 1991-2012 Free Software Foundation, Inc.
-^
bufrlib.prm(1): error #5149: Illegal character in statement label field  [C]
/* Copyright (C) 1991-2012 Free Software Foundation, Inc.
---^
bufrlib.prm(1): error #5149: Illegal character in statement label field  [o]
/* Copyright (C) 1991-2012 Free Software Foundation, Inc.
----^
bufrlib.prm(1): error #5118: First statement in file must not be continued
/* Copyright (C) 1991-2012 Free Software Foundation, Inc.
-----^
bufrlib.prm(2): error #5149: Illegal character in statement label field  [T]
   This file is part of the GNU C Library.
---^
bufrlib.prm(2): error #5149: Illegal character in statement label field  [h]
   This file is part of the GNU C Library.
----^
bufrlib.prm(4): error #5149: Illegal character in statement label field  [T]
   The GNU C Library is free software; you can redistribute it and/or
---^
bufrlib.prm(4): error #5149: Illegal character in statement label field  [h]
   The GNU C Library is free software; you can redistribute it and/or
----^
bufrlib.prm(1): error #5082: Syntax error, found INTEGER_CONSTANT '1991' when expecting one of: => = . [ % (
/* Copyright (C) 1991-2012 Free Software Foundation, Inc.
-----------------^
bufrlib.prm(5): error #5149: Illegal character in statement label field  [m]
   modify it under the terms of the GNU Lesser General Public
---^
bufrlib.prm(5): error #5149: Illegal character in statement label field  [o]
   modify it under the terms of the GNU Lesser General Public
----^
bufrlib.prm(6): error #5149: Illegal character in statement label field  [L]
   License as published by the Free Software Foundation; either
---^
bufrlib.prm(6): error #5149: Illegal character in statement label field  [i]
   License as published by the Free Software Foundation; either
----^
bufrlib.prm(4): error #5082: Syntax error, found '/' when expecting one of: => = . [ % ( :
   The GNU C Library is free software; you can redistribute it and/or
------------------------------------------------------------------^
bufrlib.prm(7): error #5149: Illegal character in statement label field  [v]
   version 2.1 of the License, or (at your option) any later version.
---^
bufrlib.prm(7): error #5149: Illegal character in statement label field  [e]
   version 2.1 of the License, or (at your option) any later version.
----^
bufrlib.prm(9): error #5149: Illegal character in statement label field  [T]
   The GNU C Library is distributed in the hope that it will be useful,
---^
bufrlib.prm(9): error #5149: Illegal character in statement label field  [h]
   The GNU C Library is distributed in the hope that it will be useful,
----^
bufrlib.prm(10): error #5149: Illegal character in statement label field  [b]
   but WITHOUT ANY WARRANTY; without even the implied warranty of
---^
bufrlib.prm(10): error #5149: Illegal character in statement label field  [u]
   but WITHOUT ANY WARRANTY; without even the implied warranty of
----^
bufrlib.prm(7): error #5082: Syntax error, found INTEGER_CONSTANT '1' when expecting one of: <IDENTIFIER> <CHAR_CON_KIND_PARAM> <CHAR_NAM_KIND_PARAM> <CHARACTER_CONSTANT>
   version 2.1 of the License, or (at your option) any later version.
-------------^
bufrlib.prm(11): error #5149: Illegal character in statement label field  [M]
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
---^
bufrlib.prm(11): error #5149: Illegal character in statement label field  [E]
   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
----^
bufrlib.prm(12): error #5149: Illegal character in statement label field  [L]
   Lesser General Public License for more details.
---^
bufrlib.prm(12): error #5149: Illegal character in statement label field  [e]
   Lesser General Public License for more details.
----^
bufrlib.prm(14): error #5149: Illegal character in statement label field  [Y]
   You should have received a copy of the GNU Lesser General Public
---^
bufrlib.prm(14): error #5149: Illegal character in statement label field  [o]
   You should have received a copy of the GNU Lesser General Public
----^
bufrlib.prm(15): error #5149: Illegal character in statement label field  [L]
   License along with the GNU C Library; if not, see
---^
bufrlib.prm(15): error #5149: Illegal character in statement label field  [i]
   License along with the GNU C Library; if not, see
----^
bfrini.f(76): catastrophic error: Too many errors, exiting
compilation aborted for bfrini.f (code 1)
make: *** [../../libbufr_v10.2.5_4_64.a(bfrini.o)] Error 1

------------------------------------

The system configuration used is :

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Model name:            Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz

OS: CentOS

The same programs worked fine with the same compilers and flags, on Bosslinux and other CentOS systems.

Please check and let me know ..how to fix the issue.

Thanks,

Ancy

I want to use the

gfortran test.f90  -lblas -llapack

to compile the file test.f90 and want to use arpack but there is an error message:

test5.f90:(.text+0x7d9): undefined reference to `dsaupd_'
test5.f90:(.text+0x990): undefined reference to `dseupd_'
test5.f90:(.text+0xbbf): undefined reference to `dmout_'

Hello,

I recently encountered some issues reading large binary 'unformatted' Fortran files (around 30Gb) with both ifort 16 and 17.
With those versions, the reading always stops at approximately 10% of the file with
"forrtl: severe (67): input statement requires too much data, unit -129"

However with both ifort 15 or gfortran, the file is read flawlessly. I also don't have any issue with Ifort 16 and 17 for smaller files
(around 20Gb). I suspect something might have changed in the software environment/default options but I can't find it.

Best,

Thomas

Intel Fortran compiler versions 17 seem to produce segmentation faults in Linux for simple files of certain number of lines.

The following program creates a file in a loop so that the number of lines in the file increases in each step of the loop. After writing the file with line numbers (as real numbers!) on each line, the program tries to read the file back.

program test_error
  implicit none

  character(len=*), parameter :: file  = "test_error.txt"
  integer, parameter :: unit = 1, jmax = 2**16
  integer :: N, io, i, j
  real :: x

  do j = 1, jmax

    ! Write j (real valued) lines to file:
    print *,"Number of lines in file " // trim(file) // ": ", j
    open(unit, file=file, status='replace')
    do i = 1, j
      x = i
      write(unit,*) x  ! x gives error, i does not!!!
    end do
    close(unit)

    ! Read lines from file until EOF (or error):
    open(unit, file=file, status='old')
    N = 0
    do
      read(unit, *, iostat=io) x
      if (io /= 0) exit
      N = N + 1
      if (N .GT. j) print *,'  Error: Extra line ', N, ' value: ',x
    end do
    print *,'  IO status:  ', io
    print *,'  Lines read: ', N
    close(unit)

  end do

end program test_error

This works most of the time but with the file of 1023 lines the program manages to read also an imaginary 1024th line containing value 512 and then segfaults:

...
 Number of lines in file test_error.txt:         1021
   IO status:            -1
   Lines read:         1021
 Number of lines in file test_error.txt:         1022
   IO status:            -1
   Lines read:         1022
 Number of lines in file test_error.txt:         1023
   Error: Extra line         1024  value:    512.0000
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
test_error         0000000000482921  Unknown               Unknown  Unknown
test_error         0000000000480A5B  Unknown               Unknown  Unknown
test_error         000000000043AC44  Unknown               Unknown  Unknown
test_error         000000000043AA56  Unknown               Unknown  Unknown
test_error         0000000000406A09  Unknown               Unknown  Unknown
test_error         0000000000409FD6  Unknown               Unknown  Unknown
libpthread-2.17.s  00007F83A1A45100  Unknown               Unknown  Unknown
test_error         000000000045808C  Unknown               Unknown  Unknown
test_error         000000000041D11D  Unknown               Unknown  Unknown
test_error         00000000004030AB  MAIN__                     24  test_error.f90
test_error         000000000040295E  Unknown               Unknown  Unknown
libc-2.17.so       00007F83A1492B15  __libc_start_main     Unknown  Unknown
test_error         0000000000402869  Unknown               Unknown  Unknown

If the loop is continued (manually) the error appears also after every "half kiloline" (512), i.e. with files of 1023, 1535, 2047, 2559, 3071 (and so on) lines and the extra value read is similarly 512, 1024, 1536, 2048, 2560, ...

This happens in CentOS 7.2 and Ubuntu 16.04 with compiler versions 17.0.0, 17.0.1, and 17.0.2. Earlier Intel Fortran compilers (tested 14.0.1, 15.0.1, 15.0.2, and 16.0.1) do not produce the error.

Can you replicate the error? Is this a bug in the compiler or on the Linux side?

Thanks,

  Matti

We recently upgraded to ifort version 17.0.2, and a piece of code that had worked for decades suddenly broke.  I traced the problem to a call to FLOOR() with a REAL*4, and was surprised at what I found.

FLOOR(), by definition, should return the greatest integer less than or equal to its argument (http://software.intel.com/en-us/node/679278).  Thus, (x-FLOOR(x)) should never be negative.  But I have an example that violates this. Here is a very simple subroutine:

SUBROUTINE floortst(x,n)
  REAL*4 :: x, y
  INTEGER*4 :: n

  y = x*n - FLOOR(x*n)
  IF (y < 0.e0) THEN
     PRINT '("v-FLOOR(v) is negative!")'
  ELSE IF (y > 1.e0) THEN
     PRINT '("v-FLOOR(v) is >1!")'
  ELSE
     PRINT '("v-FLOOR(v) lies within [0,1]")'
  END IF
  RETURN

END SUBROUTINE floortst

It should always print "v-FLOOR(v) lies within [0,1]".  However, when I compile this code with "-O1 -xAVX2" using ifort 17.0.2, and call the routine with arguments n=400000 and x=0.3496874869e0, it prints "v-FLOOR(v) is negative!".  I get the expected behavior if I remove -xAVX2 or change -O1 to -O0, so the issue appears to be an AVX2-specific optimization.  (I am running the code on an i7-7700.)

To be clear, I understand that the optimizer can make some modifications that impact floating point accuracy, but an optimization that causes x-FLOOR(x) to be negative seems spectacularly unsafe.  Am I missing something, or is this really the expected behavior?

By the way, the above code works as expected for all versions of ifort and GCC that I have access to, except for ifort 17.0.2.

I'm getting a segmentation error for the following program with Intel 15-17 on linux, the program works with PGI, XL, GNU, Oracle and NAG.

https://support.hdfgroup.org/ftp/HDF5/examples/examples-by-api/hdf5-exam...

I think there is a problem with setting the callback pointer function. Using gdb, it complains in the C code that the pointer to the function is
#0 0x00007fffffffbdf4 in ?? ()

In the C function that is called by fortran it does think that it is passed this address, op=0x7fffffffbdf4

#9 0x000000000040d16f in h5literate_by_name_c (loc_id=0x7fffffffbdd0, name=0x7fffffffbde8 "group1 ", <incomplete sequence \321>, namelen=0x7fffffffb9e0,
index_type=0x1077ca4 <h5generic_flags_+4>, order=0x1077cbc <h5generic_flags_+28>, idx=0x7fffffffbd88, op=0x7fffffffbdf4, op_data=0x7fffffffbcf0, lapl_id=0x7fffffffb9f0)
at hdf5/fortran/src/H5Lf.c:1063

but in fortran, the code calling h5literate_by_name_c, gdb does not give a pointer address:

#10 0x00000000004078c8 in h5l::h5literate_by_name_f (loc_id=144115188075855872, group_name='group1 ', index_type=0, order=2, idx=0, op=..., op_data=..., return_value=0,

op=... whatever that means.

both functions can be found in the HDF5 library,

https://bitbucket.hdfgroup.org/projects/HDFFV/repos/hdf5/browse/fortran/...

https://bitbucket.hdfgroup.org/projects/HDFFV/repos/hdf5/browse/fortran/...

Thanks

Hello. I'm attempting to compile GAMESS(US) from sources using ifort compiler, but even with the environmental variables set up I get this issue:

Help me to learn and fix the problem, please. 

Hello,
I develop a FORTRAN code on a Linux system but since we did an upgrade of the system I noticed some strange behavior. I deal with huge arrays, therefore the -mcmodel=large flag is employed and the code is parallelized with OPENMPI (compiled with the Intel compiler). For optimization the -O3 flag is used. This has always worked and still does on an different system.

Since the upgrade it seems that the program skips some part of the code, following an example :

      do i=0,imax
         eta=float(i)/float(imax)
         dr_rel=0.5*(eta)

         Ru(i)=0.5*dr_rel
      enddo


      do i=0,imax
         write(*,*)i,rank,Ru(i)
      enddo

, where imax is a constant. This produces:

...
         244          40            NaN
...

Whereas if I check the value of "eta" for NaN with the function ISNAN():

      do i=0,imax
         eta=float(i)/float(imax)
         dr_rel=0.5*(eta)

         Ru(i)=0.5*dr_rel

         if(ISNAN(eta)) then
            write(*,*)'eta'
            stop
         endif
      enddo


      do i=0,imax
         write(*,*)i,rank,Ru(i)
      enddo

The output gives me a real number:
 

...
          99          25  0.1884974
...

I suspect, that the optimization just skips the loop, yet by calling the ISNAN() the loop is executed.
Moreover if I skip the -mcmodel=large flag it works perfectly fine either way. Has anyone ever seen such a behavior?
Any help is greatly appreciated!

The attached code has a function interface where the function returns an array of a size not known until runtime.  The interface module compiles just fine but compiling the module that uses the procedure pointer results in an internal compiler error with Intel 16.  I've tried to simplify the example as much as possible while still maintaining a structure similar to our real code.  I've annotated the code with the following information, but making the return array in the interface a fixed size (either through an explicit integer or changing ARRSIZE to a parameter) allows the code to compile, as does removing the 'private' from the functionInterface module.  For reference, here is the error message:

010101_14248

catastrophic error: **Internal compiler error: internal abort** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for functionUser.f90 (code 1)

The code compiles fine with Intel 14.0.4, 15.0.3, and 15.0.7.  It fails with Intel 16.0.4 and 17.0.0.  Please let me know if I'm doing something wrong.  If this is a compiler bug, please let me know if there is a better workaround than making the functionInterface module completely public.  Making the return array a fixed-size is not really an option for us.

DownloadDownload (293 Bytes)

DownloadDownload (1.05 KB)

DownloadDownload (336 Bytes)

When MODULO is called with two positive arguments, it should always produce a nonnegative value.  However, the following code, when compiled with "-xCORE-AVX2 -O1" using ifort 17.0.2, produces a negative value!

SUBROUTINE modchk(x,n)
  REAL*4    :: x, z
  INTEGER*4 :: n
  z = x*n
  z = MODULO(z,1.e0)
  IF (z < 0.e0) THEN
     PRINT '("MODULO(v,1.e0) is negative! z=",E17.10)', z
  ELSE
     PRINT '("MODULO(v,1.e0) is nonnegative, z=",E17.10)', z
  END IF
  RETURN
END SUBROUTINE modchk

PROGRAM drv
  INTEGER*4 :: n
  REAL*4    :: x
  n = 42
  x = 2.3809524e0
  CALL modchk(x,n)
END PROGRAM drv

Example output:

$ ifort -xCORE-AVX2 -O1 modulobug.f90 -o modulobug

$ ./modulobug 
MODULO(v,1.e0) is negative! z=-0.9536743164E-06

Here is some info about my processor and compiler:

$ uname -a
Linux orpheus 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ ifort -v
ifort version 17.0.2

This is quite a serious problem because it directly violates the MODULO documentation.  Many numerical codes (e.g. table based interpolation) use MODULO and do not check the sign of the return value when it is known that the arguments will be positive.

Hi guys,

I am newly coming, and feel sorry for what I gonging to asking for, because this question may not belong to this forum. But I don't know where to ask for help.

I am using Ubuntu14.0/g++/g77 to make my project. Part of my old code as fallow:

!-------------------------------------------------------------------------------
        pointer (p_FX1, buf_FX1), (p_FY1, buf_FY1), (p_FX2, buf_FX2) 
        pointer (p_FY2, buf_FY2) 
        pointer (p_image3, buf_image3)
        pointer (p_image5, buf_image5)

        pointer (p_PreOrg, buf_PreOrg)
        pointer (p_SubOrg, buf_SubOrg)
 

        real*4 buf_FX1, buf_FY1        
        real*4 buf_FX2, buf_FY2
        integer*2 buf_image3        
        integer*2 buf_image5       
        integer*2 buf_PreOrg 
        integer*2 buf_SubOrg     

        ...

        p_PreOrg = malloc( ncol*nlin*2 )
        p_SubOrg = malloc( ncol*nlin*2 )

        call copy_image(image1, buf_PreOrg, ncol, nlin)

         ....

!--------------------------------------------------------------------------------

error as follow:

 Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
           pointer (p_FY2, buf_FY2) 
           1                        2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
           pointer (p_image3, buf_image3)
           1                             2
Unrecognized statement name at (1) and invalid form for assignment or statement-function definition at (2)
           pointer (p_image5, buf_image5)

How can fix this?

Thanks!

We would like to invite you to participate in the Intel® Parallel Studio XE 2018 Beta program. In this beta test, you will gain early access to new features and analysis techniques. Try them out, tell us what you love and what to improve, so we can make our products better for you. 

Registration is easy. Complete the pre-beta survey, register, and download the beta software:

Intel® Parallel Studio XE 2018 Pre-Beta survey

The 2018 version brings together exciting new technologies along with improvements to Intel’s existing software development tools:

Modernize Code for Performance, Portability and Scalability on the Latest Intel® Platforms

• Use fast Intel® Advanced Vector Extensions 512 (Intel®AVX-512) instructions on Intel® Xeon® and Intel®Xeon® Phi™ processors and coprocessors
• Intel® Advisor - Roofline finds high impact, but under optimized loops
• Intel® Distribution for Python* - Faster Python* applications
• Stay up-to-date with the latest standards and IDE:
  • C++2017 draft parallelizes and vectorizes C++ easily using Parallel STL*
  • Full Fortran* 2008, Fortran 2015 draft
  • OpenMP* 5.0 draft, Microsoft Visual Studio* 2017
• Accelerate MPI applications with Intel® Omni-Path Architecture

Flexibility for Your Needs

• Application Snapshot - Quick answers:  Does my hybrid code need optimization?
• Intel® VTune™ Amplifier – Profile private clouds with Docker* and Mesos* containers, Java* daemons

And much more…

For more details about this beta program, a FAQ, and What’s New, visit: Intel® Parallel Studio XE 2018 Beta page.

As a highly-valued customer and beta tester, we welcome your feedback to our development teams via this program at our Online Service Center.

Hi,

On a work server we have installed the intel compiler using Parallel studios 2017 update 2 cluster edition. We are most of the way through our 30-day evaluation period with having trouble getting wps and wrf to compile.

After finding the fix to the wps and wrf compile issues they both compiled correctly using ifort. When trying to run the built executable (mainly in WPS) i firstly get an error which links back to an intel compiler error i think where it cannot open libifort.so.5. Sourcing the intel compiler fixes this, however i then get an error saying undefined symbol when trying to run one executable. Looking back at the compile logs i can see there was a command line warning where it ignored -f90=ifort, could this be the issue with the the undefined symbol error?

when running these built executables do we need to source the ifort compilers every time?

On my own laptop i have installed the parallel studios 2017 update 3 cluster edition and i firstly dont get this -f90=ifort warning in the compile logs and when running the executables i dont need to source the intel compilers into any path or LD library path. I have followed the same steps on both machines to install intel compilers, the dependant libraries, WRF and WPS. The only difference is that one is running debian 64bit and the other is centos7 64bit with the centos7 one being the server with the issue.

I found one forum post which suggested it could be a glibc library issue with a conflicting 32bit and 64bit version install when installing the intel compiler.

Any suggestions as to how to fix these errors and why the difference in the different servers?

Adam

What happened to this once so great compiler? Since v17 and now in 18beta so many things are broken? How could that happen? I will try to come up with a list of issues, but I'm really frustrated. The full test case is here: http://www.hepforge.org/archive/whizard/whizard-2.4.1.tar.gz

Note that you need OCaml besides the ifort compiler. Just do configure, make, and then make check. 4 of 114 unit tests fail, and 127 of 224 functional tests. I'm not yet sure whether these are the same issue(s) that I already reported for the 17.0.X version of ifort. I will try to reduce this.

$ cat test_pack.f90
program test

  implicit none
 
  integer, parameter :: m = 1050000
  integer, allocatable :: a(:),b(:),c(:),d(:)

  integer :: i

  allocate(a(0:m),b(0:m),c(0:m),d(0:m))

  do i=0,m
    a(i) = i
    b(i) = 0
  end do

  d = pack(a,b == 1,c)

  deallocate(a,b,c,d)
 
end program test
$ ifort -V test_pack.f90
Intel(R) Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 17.0.1.132 Build 20161005
Copyright (C) 1985-2016 Intel Corporation.  All rights reserved.

 Intel(R) Fortran 17.0-1632
GNU ld version 2.25.1-22.base.el7
$ ./a.out
forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source             
a.out              00000000004744F1  Unknown               Unknown  Unknown
a.out              000000000047262B  Unknown               Unknown  Unknown
a.out              000000000043D3D4  Unknown               Unknown  Unknown
a.out              000000000043D1E6  Unknown               Unknown  Unknown
a.out              000000000041E1F9  Unknown               Unknown  Unknown
a.out              00000000004031C6  Unknown               Unknown  Unknown
libpthread-2.17.s  00007F416A398370  Unknown               Unknown  Unknown
a.out              0000000000402CFE  Unknown               Unknown  Unknown
a.out              000000000040295E  Unknown               Unknown  Unknown
libc-2.17.so       00007F4169FE9B35  __libc_start_main     Unknown  Unknown
a.out              0000000000402869  Unknown               Unknown  Unknown

It works with m = 1040000. the presence of the vector (c in pack(a,b == 1,c)) also has an effect on how large m can be without giving the problem.

My code base is very large and uses many different module files.  I am trying to use the code coverage tool with intel 16.0.3.210 on linux to see how much of the code actually gets used.  My compile creates 6 different libraries (.a files) in 6 different folders, and then they are linked at the end.  When I compile using the option  "-prof-gen=srcpos", each folder has a single pgopti.spi and pgopti.spl file with all of the .o and .mod files. When everything is linked together, the executable is created but there is no pgopti.spi file in the executable directory.  I tried to run the program, and there was no .dyn file generated, so I can't use the code coverage tool.  

1.  Should I only get the single pgopti file in each folder, or am I just overwriting it with each new object file I compile?

2. Does the code coverage tool only work on a single file, or should I be able to use it with multiple module files?  If so, what step am I missing to get it to work?

3.  Does it work for static and/or dynamically linked executables?

Thanks for the help