I am still involved with a legacy program that has many very old components (30 - 40 years old).  We have recently migrated from g77 to Intel Fortran, and things are going well.  Recently, the original author summarized a test that he ran, and mentioned that g77 and ifort behave differently when "array overruns" occur, i.e., an out-of-bounds array index is referenced.  So I suggested we try catching array overruns when they occur, i.e., not wait for memory corruption, and use '-check bounds' when we run tests.

I am very impressed by how this compiler option works.  In half a day, I have found about a dozen array overruns (even caught one at compile time!), and have not even begun to execute realistic scenarios.  In an application this old, we will find many more, I am sure, and it will further contribute to the robustness of the program.

Just one issue:  When I execute under gdb and an index out-of-bounds is discovered, the program does not break immediately into gdb.  Rather, the error is reported, and gdb is entered after the program terminates.

We are using version 15, update 2, on Red Hat Enterprise Linux 6.

Here is a tiny example.  I have purposely created a test case with ancient style that matches the old code.

      PROGRAM TEST
      INTEGER I,ARR(100)
      I=0
1     I=I+1
      ARR(I)=I
      PRINT *,I
      GOTO 1
      END

The idea is that we have an array of 100 elements, and march right through the end until we are "caught".  Each index is printed as we go.

First, I compile with: ifort -c -debug test.for

If I run without gdb, the program simply dies when I get to I=568.  So I run with gdb, and it breaks into gdb when it detects something is wrong (too late, of course):

         567
         568
Program received signal SIGSEGV, Segmentation fault.
0x0000003b6de093a0 in pthread_mutex_lock () from /lib64/libpthread.so.0
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.9.x86_64 libgcc-4.4.7-11.el6.x86_64
(gdb) bt
#0  0x0000003b6de093a0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x000000000040f931 in for__aio_acquire_lun ()
#2  0x0000000000428613 in for__acquire_lun ()
#3  0x0000000000408ad9 in for_write_seq_lis ()
#4  0x0000000000402d20 in test () at test.for:6
#5  0x0000000000402c7e in main ()
(gdb) bt
#0  0x0000003b6de093a0 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x000000000040f931 in for__aio_acquire_lun ()
#2  0x0000000000428613 in for__acquire_lun ()
#3  0x0000000000408ad9 in for_write_seq_lis ()
#4  0x0000000000402d20 in test () at test.for:6
#5  0x0000000000402c7e in main ()

As usual, I can get a complete backtrace.

Next, I compile with: ifort -c -debug -check bounds test.for

Running without gdb, the program now correctly crashes when I get to 101:

          99
          100
forrtl: severe (408): fort: (2): Subscript #1 of the array ARR has value 101 which is greater than the upper bound of 100
Image              PC                Routine            Line        Source            
test               0000000000404860  Unknown               Unknown  Unknown
test               0000000000402DAA  Unknown               Unknown  Unknown
test               0000000000402C7E  Unknown               Unknown  Unknown
libc.so.6          0000003B6DA1ED5D  Unknown               Unknown  Unknown
test               0000000000402B89  Unknown               Unknown  Unknown

 
In a program this small, the location of the bug is obvious.  But in a large program, just knowing the name of the array is not always enough information to find the place in the code where the overrun occurs.  So I run with gdb ,and the following occurs:

          99
         100
forrtl: severe (408): fort: (2): Subscript #1 of the array ARR has value 101 which is greater than the upper bound of 100
Image              PC                Routine            Line        Source            
test               0000000000404860  Unknown               Unknown  Unknown
test               0000000000402DAA  Unknown               Unknown  Unknown
test               0000000000402C7E  Unknown               Unknown  Unknown
libc.so.6          0000003B6DA1ED5D  Unknown               Unknown  Unknown
test               0000000000402B89  Unknown               Unknown  Unknown
Program exited with code 0230.
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.9.x86_64 libgcc-4.4.7-11.el6.x86_64
(gdb) bt
No stack.

In other words, the crash is detected as before, but break in the program is too late, so the backtrace does not guide me to the line of code where the error is detected.

Jay 

This topic must have been beaten to death, but the issue I've encountered seems very odd.

Here is the C code:

void test_array(int *, int *, double **); // To test accessing a Fortran 2D array.

void test_get_array()

{

    int i;

    int narr1, narr2;

    double *farr;

    test_array(&narr1, &narr2, &farr);

    for (i=0;i<narr1*narr2; i++)

        printf("%d %f\n",i,farr[i]);

}

and the Fortran:

subroutine test_array(narr1, narr2, cptr) bind(C)
!DEC$ ATTRIBUTES DLLEXPORT :: test_array
use, intrinsic :: iso_c_binding
integer(c_int) :: narr1, narr2
TYPE (C_PTR)    :: cptr
real(c_double), allocatable, target :: a(:,:)
integer :: i1, i2
integer :: n1=4, n2=3

allocate(a(n1,n2))
do i1 = 1,n1
    do i2 = 1,n2
        a(i1,i2) = i1 + 10*i2
    enddo
enddo

narr1 = n1
narr2 = n2
cptr = c_loc(a)
write(*,'(4f6.0)') a

end subroutine

This is the output:

11. 12. 13. 14.

21. 22. 23. 24.

31. 32. 33. 34.

0 0.000000

1 12.000000

2 13.000000

3 14.000000

4 21.000000

5 22.000000

6 23.000000

7 24.000000

8 31.000000

9 32.000000

10 33.000000

11 34.000000

What has happened to the first array entry?

Hang on!  I just remembered seeing something about SAVE.  When I add that to the declaration of a(:) I get the first entry correctly.  I'm guessing that not SAVEing immediately clobbers the start of the array somehow on subroutine return.  I decided to leave the post here because the phenomenon is interesting and I'd like to see comments on it.

Thanks

Gib

This will not be an easy question to handle for anyone as it involves a lot of variables. We shifted on to Windows 8.1 and started observing this issue.

OS: Windows 8.1 Enterprise

VS: Visual Studio 2008 SP1

VF: Intel(R) Visual Fortran Compiler Integration for Microsoft Visual Studio* 2008, 11.1.3469.2008

When you have variables added to the watch window and are stepping through the code (F10), Visual Studio can take up to 3 seconds going through each line when going through Fortran projects. The mouse cursor would change to waiting (small circle) when the program is waiting to move to the next line. This depends on the number of variables that are being added to the Watch window i.e. a couple of variable then wait time may be less than 0.1 second, up to say 50 variables wait time > 3 seconds each line. If you get rid of all the variables in the watch window, debugging would run smoothly without any delays.

We started observing this issue with Windows 8.1. Windows 7 did not have this issue keeping all the other installations the same. I tried to reproduce the same issue on a VM, but could not and the debugging ran smoothly for the same project regardless of the number of variable added to the watch window. May be it is because of some Hotfix.

This is really frustating to us, and any help from your guys would be hugely appreciated.

Thank you.

Another issue while experimenting with type bound operators: ifort (version 15.0) rejects the attached code, which I think is correct (some comments in the code itself, close to the line producing the error).

$ ifort -c test.f90

test.f90(34): warning #6178: The return value of this FUNCTION has not been defined.   [Y]
 pure recursive function unpck(x) result(y)
-----------------------------------------^
test.f90(40): warning #6178: The return value of this FUNCTION has not been defined.   [Z]
 elemental function cont_add(x,y) result(z)
-----------------------------------------^
test.f90(70): warning #6178: The return value of this FUNCTION has not been defined.   [Z]
 elemental function add(x,y) result(z)
------------------------------------^
test.f90(126): error #6355: This binary operation is invalid for this data type.   [DAT]
     allocate( z%f , source=new_t_b( x%dat + yunp ) )
---------------------------------------^
test.f90(126): error #6355: This binary operation is invalid for this data type.   [YUNP]
     allocate( z%f , source=new_t_b( x%dat + yunp ) )
---------------------------------------------^
test.f90(126): error #6549: An arithmetic or LOGICAL type is required in this context.
     allocate( z%f , source=new_t_b( x%dat + yunp ) )
-------------------------------------------^
test.f90(100): warning #6178: The return value of this FUNCTION has not been defined.   [NEWB]
 pure function new_t_b(dat) result(newb)
-----------------------------------^
compilation aborted for test.f90 (code 1)

module m1

 implicit none

 public :: &
   t_abstr, t_cont, unpck

 private

 type, abstract :: t_abstr
 contains
  private
  generic, public :: operator(+) => add
  procedure(i_add), pass(x), deferred :: add
 end type t_abstr

 type, extends(t_abstr) :: t_cont
  class(t_abstr), allocatable :: f
 contains
  procedure, private, pass(x) :: add => cont_add
 end type t_cont

 abstract interface
  elemental function i_add(x,y) result(z)
   import :: t_abstr, t_cont
   implicit none
   class(t_abstr), intent(in) :: x, y
   type(t_cont) :: z
  end function i_add
 end interface

contains

 pure recursive function unpck(x) result(y)
  class(t_abstr), intent(in) :: x
  class(t_abstr), allocatable :: y

 end function unpck

 elemental function cont_add(x,y) result(z)
  class(t_cont), intent(in) :: x
  class(t_abstr),  intent(in) :: y
  type(t_cont) :: z

 end function cont_add

end module m1

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

module m2

 use m1, only: &
   t_abstr, t_cont, unpck

 implicit none

 public :: &
   t_a

 private

 type, extends(t_abstr) :: t_a
 contains
  procedure, private, pass(x) :: add
 end type t_a

contains

 elemental function add(x,y) result(z)
  class(t_a), intent(in) :: x
  class(t_abstr), intent(in) :: y
  type(t_cont) :: z

 end function add
end module m2

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

module m3

 use m1, only: &
   t_abstr, t_cont, unpck

 use m2, only: &
   t_a

 implicit none

 private

 type, extends(t_abstr) :: t_b
  type(t_cont), allocatable :: dat(:)
 contains
  procedure, pass(x) :: add
 end type t_b

contains

 pure function new_t_b(dat) result(newb)
  type(t_cont), intent(in) :: dat(:)
  type(t_b) :: newb

 end function new_t_b

 elemental function add(x,y) result(z)
  class(t_b), intent(in) :: x
  class(t_abstr), intent(in) :: y
  type(t_cont) :: z

  class(t_abstr), allocatable :: yunp

   allocate( yunp , source=unpck(y) )
   select type(yunp)
    type is(t_a)

     ! Note:
     !
     ! x%dat has type  type(t_cont), allocatable, dimension(:)
     ! yunp has type  type(t_a)
     !
     ! Since both  t_cont  and  t_a  extend  t_abstr, the elemental
     ! type bound function "add" should be called. In particular,
     ! given that the first argument is the passed one, x%dat%cont_add
     ! should be called.
     allocate( z%f , source=new_t_b( x%dat + yunp ) )

   end select

 end function add

end module m3

Dear all,

I would like to create a program with #ifdef and #endif compilation options  but I do not know how could i compile even tis simple hello program:

PROGRAM HELLO
IMPLICIT NONE

#ifdef PARALLEL
  WRITE(*,*) 'OPTION A'
#endif

 WRITE(*,*) 'OPTION A+B'

END PROGRAM

When I compile, I get this error:

hello.f90(4): warning #5117: Bad # preprocessor line
#ifdef PARALLEL
-^
hello.f90(6): warning #5117: Bad # preprocessor line
#endif

Can someone explain me how to compile and activate or not activate options A and B.

Really Really thanks

Greetings,

I'm writing an ABAQUS FILM user subroutine.  The subroutine uses many supporting modules to get the job done, and works well with a dummy driver.  I'm most experienced writing stand-alone code, i..e., main + subs.  How do I compile in Visual Studio to create a single *.obj with only the sub and supporting modules to present to ABAQUS?  Excluding the main dummy program from the build generates an error regarding the missing external routine.  Failing that can I manually concatenate the many obj files VS makes into a single file, or must I concatenate the modules' source code to generate a single obj file?

Also: How can I get Visual Studio to create a makefile (NMAKE?) from the IDE so other users can recompile from the command line?  The HELP leaves me confused.  Creating a Makefile from scratch is always a painful exercise for me, and presenting the many supporting modules to the linker begs for a script.

Thanks,

John W

Hi, Guys,

Does anyone see this warning message before?

How to fix it?

Incorrect setting of the registers of the graphics chip:

Jul 6 18:54:51 i7IvyBridge kernel: [drm] Wrong MCH_SSKPD value: 0x20100406

Jul 6 18:54:51 i7IvyBridge kernel: [drm] This can cause pipe underruns and display issues.

Jul 6 18:54:51 i7IvyBridge kernel: [drm] Please upgrade your BIOS to fix this.

The compiler error with the following code appears to be incorrect:

module m

   implicit none

   private

   type, public :: t
      private
      integer, pointer :: m_i
   contains
      private
      procedure, pass(this), public :: iptr => getptr
      procedure, pass(this), public :: setptr
   end type t


contains

   subroutine setptr( this, iptr )

      !.. Argument list
      class(t), intent(inout)         :: this
      integer, pointer, intent(inout) :: iptr

      this%m_i => iptr

      return

   end subroutine setptr

   function getptr( this ) result( iptr )

      !.. Argument list
      class(t), intent(in) :: this
      !.. Function result
      integer, pointer :: iptr

      iptr => this%m_i

      return

   end function getptr

end module m

program p

   use m, only : t

   integer, pointer :: i
   type(t) :: foo

   print *, " Is i associated with foo%iptr? ", associated( i, foo%iptr() )

   stop

end program p

Compiling with Intel(R) Visual Fortran Compiler XE 15.0.4.221 [Intel(R) 64]...
p.f90
C:\..\p.f90(8): error #6808: The TARGET argument must have the POINTER or TARGET attribute.
[ASSOCIATED]
compilation aborted for C:\..\p.f90 (code 1)

When I Debug the attached code with VS2010 and IVF XE2013 (and 2011 on colleagues machine) on entering the subroutine SCALC, after a break point has been placed at line 448, causes Visual Studio (VS) to stop working (crash).  Debugging VS in another instance of VS states that a buffer overrun in devenv.exe has corrupted the programs internal state.  With no break point, or in Release mode, the program executes and terminates normally.

This code is from a large legacy Fortran program (650+ routines) and I have distilled down to just a few lines to demo issue.  The original code is characterised by very large argument lists being passed between subroutines.  However, it has been compiled with IVF for many years without issue.  Although I agree that the code style is legacy and ugly I do not think it breaks any basic rules.  I have checked that the argument list between the calling program and SCALC is consistent.  I tried varying the size of argument FEF (hardcoded to 100) and found that the code debugs normally if set to 99.  However, it could also be increased if the argument position was changed.  i.e. This seems like a real flaky memory issue but I cannot see anything wrong in the code and so I am starting to wonder if it is from the development environment.

I attach the VS project and source file: crash.f - please see if you can verify.  i.e.  (1) Open project with VS, (2) Insert a break point at line 448, and see if you can (3) Debug to this break point without crash.  If your test also crashes I would be grateful if you have any suggestions.  Jon

Dear DZ

I have just updatet my fortran compiler under WS(Professional 2013 - update 4) with Intel® Parallel Studio XE Composer Edition for Fortran Windows*.

Unfortunately, my code is no longer able to maintain the same calculation accuracy (machine eps = 1.2D-19) using the ifport modules (GETCONTROLFPQQ and SETCONTROLFPQQ), se the below code, which now creates the standard machine eps = 2.2D-16.

Are there any compiler settings to fix that problem, any guidance???

Thanks in advance!

Regards

Axel Ohrt Johansen

subroutine fpprecis()

use ifport

use dflib

integer(2) control, holdcontrol, newcontrol

real(8) A,EPSMAC

CALL GETCONTROLFPQQ(control)

! Clear any existing precision flags.

holdcontrol = IAND(control, NOT(FPCW$MCW_PC))

newcontrol = IOR(holdcontrol, FPCW$64)

! Set precision to 64 bits.

CALL SETCONTROLFPQQ(newcontrol)

! Test - machine eps:

EPSMAC=1.0D0

100 EPSMAC=EPSMAC/2.0D0

A=EPSMAC+1.0D0

IF(A.NE.1.0D0) GO TO 100

EPSMAC=2.0D0*EPSMAC

Write(6,*) EPSMAC

end subroutine fpprecis

Duplicate.

Hi,

I need to install and build PETSc with Intel MPI and compilers. It has so far been unsuccessful.

It seems that I need to know which mpi libraries to link to

The compiling and building is done in cygwin64.

The commands are:

export PETSC_DIR=`pwd`

export PETSC_ARCH=petsc-3.6.0_win64_impi_vs2012_debug

I then tried the 4 options below but they all failed. Does anyone manage to get it working?

1. ./config/configure.py --with-cc='win32fe mpiicc.bat' --with-fc='win32fe mpiifort.bat' --with-cxx='win32fe mpiicpc.bat' --with-blas-lapack-dir=/cygdrive/c/Program\ Files\ \(x86\)/Intel/Composer\ XE\ 2015/mkl/ --prefix=/cygdrive/c/wtay/Lib/petsc-3.6.0_win64_impi_vs2012_debug --with-debugging=1

2. ./config/configure.py --with-cc='win32fe cl' --with-fc='win32fe ifort' --with-cxx='win32fe cl' --with-mpi-include=/cygdrive/c/Program\ Files\ \(x86\)/Intel/MPI/5.0.3.048/intel64/include --with-mpi-lib="/cygdrive/c/Program Files (x86)/Intel/MPI/5.0.3.048/intel64/lib/impi.lib" --with-blas-lapack-dir=/cygdrive/c/Program\ Files\ \(x86\)/Intel/Composer\ XE\ 2015/mkl/ --prefix=/cygdrive/c/wtay/Lib/petsc-3.6.0_win64_impi_vs2012_debug --with-debugging=1

Also, how can I get intel premier support? It says not authorized. I've already registered my product (cluster edition 2015).

Thank you.

Dear All,

There appears to be an obscure bug in version 15 of the Fortran compiler involving MPI, OpenMP and string passing all together.

We're running on Intel hardware under Linux. First the compiler:

mpif90 --version

ifort (IFORT) 15.0.3 20150407
Copyright (C) 1985-2015 Intel Corporation.  All rights reserved.

... now the smallest code I could devise which still has the bug:

program test
implicit none
integer i
!$OMP PARALLEL DEFAULT(SHARED)
!$OMP DO
do i=1,10
  call foo
end do
!$OMP END DO
!$OMP END PARALLEL
end program

subroutine foo
implicit none
character(256) str
call bar(str)
return
end subroutine

subroutine bar(str)
implicit none
character(*), intent(out) :: str
write(str,'(I1)') 1
return
end subroutine

... compiling with:

mpif90 -openmp test.f90

... results in code which crashes randomly with OMP_NUM_THREADS greater than one. This does not occur with version 14 of the compiler.

Regards,

John.

Dear folks,

I am using

>ifort -O3 -xHost -ipo

to compile a huge program package including a NAG Library file and get the following error message:

NAG_TProp.f(8887): remark #7922: The value was too small when converting to REAL(KIND=8); the result is in the denormalized range.   [1.11253692925361D-308]
      DATA X02CON /1.11253692925361D-308 /
-------------------^

The corresponding function in the file in which the error occurs looks like this

      DOUBLE PRECISION FUNCTION X02AMF()
C     MARK 12 RELEASE. NAG COPYRIGHT 1986.
C
C     RETURNS THE 'SAFE RANGE' PARAMETER
C     I.E. THE SMALLEST POSITIVE MODEL NUMBER Z SUCH THAT
C     FOR ANY X WHICH SATISFIES X.GE.Z AND X.LE.1/Z
C     THE FOLLOWING CAN BE COMPUTED WITHOUT OVERFLOW, UNDERFLOW OR OTHER
C     ERROR
C
C        -X
C        1.0/X
C        SQRT(X)
C        LOG(X)
C        EXP(LOG(X))
C        Y**(LOG(X)/LOG(Y)) FOR ANY Y
C
      DOUBLE PRECISION X02CON
      DATA X02CON /1.11253692925361D-308 /
C     .. Executable Statements ..
      X02AMF = X02CON
      RETURN
      END

My ifort version is

>ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.1.133 Build 20141023
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Is this a compiler problem? Are there any option I could try? I also couldn't find a 'newer' version of the NAG Routine online, so I can't tell if this occurs only with this quite old version.

Thank you in advance,

Maja

Hi,

while importing the open-source project CP2K, I came across a problem with parsing the input files. Opening the attached file d3_poly.F in Visual Studio 2015 with Intel Parallel Studio XE 2015 U4 immediately crashes the Visual Studio UI for me. Can anybody confirm this issue?

Kind regards,

Guido

I just purchased Intel Fortran 2015.3.187 for OSX. I'm using XCODE 6.4. It seems XCODE cannot detect fortran compiler. What should I do? Do I need to obtain lower version of XCODE?

Hello,

I am using Parallel Studio XE2015 to compile a program that was compiled with Visual Fortran in the past. It looks like the compiler is ignoring !DIR$ and cDEC$ compiler directives. Initially, I thought cDEC$ had been deprecated, but !DIR$ is also being ignored. Do I need a special compilation switch?  The program uses mostly fixed-form 72-column code, but it uses longer fixed-form code and freeform code in a few places, and I need the directives for this purpose.

BTW, I have enabled the pre-processor (/fpp); does it interfere with these directives?

Any suggestions?

Thanks,

Gabriel

I am just wondering what might be the reason(s) for IMSL numeric libraries being unavailable as add-ons or a bundled feature with Intel Fortran for Linux?

Is then purchasing it directly from Rogue Wave the only option?

Best regards,

Vladimir

Is there going to be an Update 4 for Composer Edition for Fortran Linux Version 2015 released in the near future?

Update 3 came out on 13 Apr 2015. I can see that there is an Update 4 for Composer Edition for Fortran and C++ Windows (released on 13 May). Is there going to be an Update 4 for the Linux compilers also?

I am now using the Parallel Studio XE 2015 Composer Edition for Fortran combined with Xcode 6.3 to run a program.

The program was made in order to read data from file first and then go for some further computation.

I had all my f90 files (including the main program and the modules) in the Project folder and it did compile and run.

But when I tried to input the file name and load the file, it seemed that it failed to read the file.

I have my code like this

.......

CHARACTER(LEN = 20) :: fileName

INTEGER :: iNode

REAL(KIND = dp) :: xBox, yBox, zBox

WRITE(*,'(A)', ADVANCE = "NO") "Input file name: "

READ(*,*) fileName

OPEN(1, FILE = TRIM(fileName)//'.in' , STATUS = 'UNKNOWN')

READ(1,*) iNode, xBox, yBox, zBox

........

When I ran the program and input the file name it simply returned forrtl: severe (24): end-of-file during read, unit 1...

I though it might be due to failure to find the file though I had put the data file (output.in) in the same folder as other .f90 files, as well as add it to the project. 

I am just wondering how to deal with this issue (I thought it might be a reference/file location issue of Xcode, since this program is running well on other fortran compiler.)

Thanks.

-Abright