Hello,

I'm new to FORTRAN, I'm using Thermal Desktop (built into AutoCAD) and SINDA/FLUINT to run thermal analysis. I got the following error message from SINDA/FLUINT:

Compile or link of astap.for failed- see messages_"xxx.txt" in your input file subdirectory.

That text file states the following:

Current Patch Level = 4
Version = 5.7 Intel Fortran

ifort /Qopenmp /fpe:0 /real_size:64 /integer_size:64 /names:lowercase /iface:cref /I:C:\PROGRA~1\CULLIM~1\SINDAF~1\mod /MD /iface:mixed_str_len_arg /include:C:\PROGRA~1\CULLIM~1\SINDAF~1\lib /assume:byterecl /extend_source:132 /O3 /traceback /INCREMENTAL:NO

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.1.3.198 Build 20130607
Copyright (C) 1985-2013 Intel Corporation.  All rights reserved.

ifort: error #10037: could not find 'link'

I already uninstalled and reinstalled my software to make sure that wasn't the issue. Not sure what to do now, I googled ifort: error #10037: could not find 'link' and it brought me to the intel developer zone website.

Thanks for your help,

Doug

dear all,

I would like to know how works the allocatable variable type in and out a subroutine

This is my problem.

I have this variable type:

  TYPE tParticle
    SEQUENCE
    INTEGER               :: ip
    INTEGER               :: mc
    INTEGER               :: bcflag
    INTEGER               :: cpu
    REAL    ,ALLOCATABLE  :: RP(:)
    REAL    ,ALLOCATABLE  :: QQ(:)
    REAL    ,ALLOCATABLE  :: UU0(:)
    REAL                  :: lij
    REAL                  :: lmls
    REAL                  :: vol
  ENDTYPE tParticle

and I allocate it in the following way:

  ALLOCATE (PART          (nptPbuffer))

 DO ip=1,nptPbuffer
     ALLOCATE(PART(ip)%RP(di))
     ALLOCATE(PART(ip)%QQ(nVar))
     ALLOCATE(PART(ip)%UU0(countBufferRK))
ENDDO

Here the problem: how can I pass the variable type?

Here an example:

SUBROUTINE SPH(nptTot,PART)
 TYPE(tParticle),DIMENSION(nptTot)      ,INTENT(IN)  :: PART

is it correct?

How can I deallocate the variable type? Can I simple do:

DEALLOCATE(PART)

thank to all of you

After importing a project from CVF, there are a bunch of "project" files which are listed below. Which of these are no longer needed and safe to delete? Also, why are there both vcxproj and vfproj files?

HsealH.dsp
HsealH.dsw
HsealH.ncb
HsealH.opt
HsealH.plg
HsealH.sdf
HsealH.sln
HsealH.suo
HsealH.vcxproj
HsealH.vcxproj.filters
HsealH.vcxproj.user
HsealH_.u2d
HsealH_.vfproj
HsealH_log.txt

I have a problem with a program which, when compiled with ifort,  throws a 'segmentation fault' when running under fedora (tried 16 and 22) but not when running under Ubuntu  (14.04) or CentOS (6). the same program compiled with Lahey LF64 or gfortran runs o.k. on all platforms (but I would like the better performance ifort gives me). I have compiled all three compiler versions with array bound and other error checking switched on and not been able to identify any errors; I've also tried different ifort versions (13.0.1.117 and 15.02.164) but  nothing seems to make any difference. I have traced the error to be occurring at a subroutine call (printed out screen messages just before the call & as the 1st statement in the subroutine - the latter didn't show up) and double-checked that all parameters passed are o.k.

my questions: has anybody encountered something like this? any suggestions what else I might try to resolve this.

Hi, i ran into a problem with parameterized derived types. If i try to compile the following code with the 15.0.4 Compiler on Windows i get error 6633
"The type of the actual argument differs from the type of the dummy argument.   [A]". (in Line 37)

module M_MATRIX
  use, intrinsic :: iso_fortran_env, only: real64
  type, public :: DT_MATRIX(knd, k, n)
    integer, kind :: knd
    integer, len  :: k
    integer, len  :: n
    real(kind = knd), dimension(k,n) :: m
  end type
end module M_MATRIX

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

module M_EXAMPLE
  use M_MATRIX
!  public           ! <- compiles

  private            !
  public :: foo      ! <- does not compile

  contains
  subroutine foo(matrix)
    type(DT_MATRIX(real64,2,2)) :: matrix
    matrix%m = 0.0d0
  end subroutine

end module M_EXAMPLE

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

program test
  use M_EXAMPLE !, only: foo ! <- "only" disables the public-workaround
  use M_MATRIX
  Implicit none

  type(DT_MATRIX(real64,2,2)) :: A

  call foo(A)

end

There seems to be no change in behavior, whether there are kind- or len-parameters in the type definition of DT_MATRIX.

As i searched the forum, i read about some bug-fixes to PTDs in the 16.0 release, so this might be unimportant.

Wolf

Dear Fortran Masters, 

I have two simple questions.

1 - In the operation x**b, where b is always an integer. Is there any loss of precision if b is declared as real(8) or integer?

2 - In the operation x**b, where b is always real positive number. Is there any loss of precision if b is declared as real(8) or real(4)?

Why or why not? Kindly advise. Thank you, Javier

program powx

	implicit none

	real(8)	:: x
	real(8)	:: a
	real(4)	:: b
	integer	:: i

	x = 1.23456789d0
	i = 4
	a = 3d0
	b = 1.23456789

	! Question 1
	write (*,*) x**(i-1), x**dble(i-1), x**a, x**3.0

	! Question 2
	write (*,*) x**1.23456789, x**dble(1.23456789), x**x, x**b

end program powx

I have Parallel Studio XE 2013 with Visual Studio 2013. .

1. I start a new IVF Project (static Lbrary)
2. In VS2013, I add a new  win32 console application to the IVF Project
3. I set the fortran function dependent to the main cpp

Please see below

//

#include "stdafx.h"
#include <iostream>

using namespace std;

extern "C"
 {
  void __cdecl FR1(int *a, int *b);
  int __cdecl FF1(int *c);
 }

int main()
{
 int n = 10;
 int nSq;
 int nCube;

 FR1(&n, &nSq);

 cout << "The square is:"<< nSq << endl;

 nCube = FF1(&n);

 cout << "The cube is:"<< nCube << endl;
 getchar();
 return 0;
}

// fortran f90

subroutine FR1(N,M)
!DEC$ ATTRIBUTES DLLEXPORT :: FR1
   
 M = N*N
return
end
   
integer function FF1(N)
!DEC$ ATTRIBUTES DLLEXPORT :: FF1
  
FF1 = N*N*N
    return
    end

I am trying to call  a fortran function f90 from C++, but i got two time the error message  LNK2019

error LNK2019: unresolved external symbol referenced "_FR1" in function _main

error LNK2019: unresolved external symbol referenced "_FF1" in function _main

 With Dumpbin /symbols I got the error message LINK: fatal error LNK1181 cannot open input file

C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC> cd c:\visual studio 2013
\Projekt2\Fortfunc\Debug

c:\visual studio 2013\Projekt2\Fortfunc\Debug>dumpbin/symbols Fortfunc.dll
Microsoft (R) COFF/PE Dumper Version 12.00.21005.1
Copyright (C) Microsoft Corporation.  All rights reserved.

Dump of file Fortfunc.dll
LINK : fatal error LNK1181: Eingabedatei "Fortfunc.dll" kann nicht geöffnet werden.

Thanks in Advance

Dear great Intel Fortran Developers team,

I would like to report a possible bug in ifort 15.0.3.

I am trying to develop an OOP library that takes advantage of Abstract Calculus Pattern by means of an abstract type definition. In a very few words, the library defines an abstract type with some operators overloading deferred and it provides a procedure that operates on the abstract type. The concrete extensions of the abstract type implement only the type bound procedures deferred whereas the overloaded operators are defined by the abstract type. The real code is here https://github.com/Fortran-FOSS-Programmers/FOODiE/blob/master/src/lib/type_integrand.f90. 

A minimal example raising the possible bug is reported below. There are 3 modules and 1 main program: 1) type_abstract_buggy provides the abstract type, 2) lib_abstract_buggy provides a procedure working on the abstract type that raises the possible bug, 3) type_buggy implements a concrete extension of the abstract type defining only the procedures for the operators overloading and 4) is the main program using the last 2 modules. 

The expected results are:

Array: 

  1.00000000
  2.00000000
  3.00000000
Scalar:     3
Array:
  2.00000000
  4.00000000
  6.00000000
Scalar:     3
Array:
  4.00000000
  8.00000000
  12.0000000
Scalar:     3
 

but when compiling with ifort 15.0.3 complains with following errors. 

ifort-bug.f90(58): error #6633: The type of the actual argument differs from the type of the dum

my argument.   [BUG]
 bug = scalar * bug
-----------------^
ifort-bug.f90(146): error #7013: This module file was not generated by any release of this compi
ler.   [LIB_ABSTRACT_BUGGY]
use lib_abstract_buggy, only : raise_bug
----^
ifort-bug.f90(149): error #6457: This derived type name has not been declared.   [BUGGY]
type(buggy) :: bug
-----^
ifort-bug.f90(151): error #6404: This name does not have a type, and must have an explicit type.
  [BUG]
bug = buggy(array=[1., 2., 3.], scalar=3)
^
ifort-bug.f90(151): error #6632: Keyword arguments are invalid without an explicit interface.   
[ARRAY]
bug = buggy(array=[1., 2., 3.], scalar=3)
------------^
ifort-bug.f90(151): error #6632: Keyword arguments are invalid without an explicit interface.   
[SCALAR]
bug = buggy(array=[1., 2., 3.], scalar=3)
--------------------------------^
ifort-bug.f90(152): error #6406: Conflicting attributes or multiple declaration of name.   [RAIS
E_BUG]
call raise_bug(bug=bug, scalar=2)
-----^
ifort-bug.f90(146): error #6580: Name in only-list does not exist.   [RAISE_BUG]
use lib_abstract_buggy, only : raise_bug
-------------------------------^
ifort-bug.f90(147): error #6580: Name in only-list does not exist.   [BUGGY]
use type_buggy, only : buggy
-----------------------^
compilation aborted for ifort-bug.f90 (code 1)
 

The compilation is done by: ifort -O0 -debug all -check all -warn all -traceback -assume realloc_lhs -std08 ifort-bug.f90

Note that the correct result is obtained by GNU gfortran 5.2.

Minimal example raising the possible compiler bug

module type_abstract_buggy
implicit none
private
public :: abstract_buggy

type, abstract :: abstract_buggy
  contains
    ! public methods
    procedure(abstract_printf), public, deferred :: printf
    generic,                    public           :: operator(*) => buggy_multiply_scalar, scalar_multiply_buggy
    generic,                    public           :: assignment(=) => buggy_assign_buggy
    ! private methods
    procedure(abstract_buggy_multiply_scalar),       pass(lhs), private, deferred :: buggy_multiply_scalar
    procedure(scalar_multiply_abstract_buggy),       pass(rhs), private, deferred :: scalar_multiply_buggy
    procedure(abstract_buggy_assign_abstract_buggy), pass(lhs), private, deferred :: buggy_assign_buggy
endtype abstract_buggy
abstract interface
  subroutine abstract_printf(self)
  import :: abstract_buggy
  class(abstract_buggy), intent(IN) :: self
  endsubroutine abstract_printf

  function abstract_buggy_multiply_scalar(lhs, rhs) result(multy)
  import :: abstract_buggy
  class(abstract_buggy), intent(IN)  :: lhs
  integer,               intent(IN)  :: rhs
  class(abstract_buggy), allocatable :: multy
  endfunction abstract_buggy_multiply_scalar

  function scalar_multiply_abstract_buggy(lhs, rhs) result(multy)
  import :: abstract_buggy
  integer,               intent(IN)  :: lhs
  class(abstract_buggy), intent(IN)  :: rhs
  class(abstract_buggy), allocatable :: multy
  endfunction scalar_multiply_abstract_buggy

  pure subroutine abstract_buggy_assign_abstract_buggy(lhs, rhs)
  import :: abstract_buggy
  class(abstract_buggy), intent(INOUT) :: lhs
  class(abstract_buggy), intent(IN)    :: rhs
  endsubroutine abstract_buggy_assign_abstract_buggy
endinterface
endmodule type_abstract_buggy

module lib_abstract_buggy
use type_abstract_buggy, only : abstract_buggy
implicit none
private
public :: raise_bug
contains
  subroutine raise_bug(bug, scalar)
  class(abstract_buggy), intent(INOUT) :: bug
  integer,               intent(IN)    :: scalar

  call bug%printf()
  bug = bug * scalar
  call bug%printf()
  bug = scalar * bug
  call bug%printf()
  endsubroutine raise_bug
endmodule lib_abstract_buggy

module type_buggy
use type_abstract_buggy, only : abstract_buggy
implicit none
private
public :: buggy

type, extends(abstract_buggy) :: buggy
  private
  real, dimension(:), allocatable :: array
  integer                         :: scalar=0
  contains
    ! public methods
    procedure, pass(self), public :: printf
    ! private methods
    procedure, pass(lhs), private :: buggy_multiply_scalar
    procedure, pass(rhs), private :: scalar_multiply_buggy
    procedure, pass(lhs), private :: buggy_assign_buggy
endtype buggy
interface buggy
  procedure create_buggy
endinterface
contains
  pure function create_buggy(array, scalar) result(bug)
  real, dimension(:), intent(IN) :: array
  integer,            intent(IN) :: scalar
  type(buggy)                    :: bug

  bug%array = array
  bug%scalar = scalar
  return
  endfunction create_buggy

  subroutine printf(self)
  class(buggy), intent(IN) :: self
  integer      :: i

  print "(A)", "Array:"
  do i=1, size(self%array)
    print*, self%array(i)
  enddo
  print "(A,I5)", "Scalar: ", self%scalar
  endsubroutine printf

  function buggy_multiply_scalar(lhs, rhs) result(multy)
  class(buggy), intent(IN)           :: lhs
  integer,      intent(IN)           :: rhs
  class(abstract_buggy), allocatable :: multy
  type(buggy),           allocatable :: multy_tmp

  allocate(buggy :: multy_tmp)
  multy_tmp%array = lhs%array * rhs
  multy_tmp%scalar = lhs%scalar
  call move_alloc(multy_tmp, multy)
  return
  endfunction buggy_multiply_scalar

  pure function scalar_multiply_buggy(lhs, rhs) result(multy)
  integer,      intent(IN)           :: lhs
  class(buggy), intent(IN)           :: rhs
  class(abstract_buggy), allocatable :: multy
  type(buggy),           allocatable :: multy_tmp

  allocate(buggy :: multy_tmp)
  multy_tmp%array = rhs%array * lhs
  multy_tmp%scalar = rhs%scalar
  call move_alloc(multy_tmp, multy)
  return
  endfunction scalar_multiply_buggy

  pure subroutine buggy_assign_buggy(lhs, rhs)
  class(buggy),          intent(INOUT) :: lhs
  class(abstract_buggy), intent(IN)    :: rhs

  select type(rhs)
  class is(buggy)
    if (allocated(rhs%array)) lhs%array = rhs%array
    lhs%scalar = rhs%scalar
  endselect
  return
  endsubroutine buggy_assign_buggy
endmodule type_buggy

program ifort_bug
use lib_abstract_buggy, only : raise_bug
use type_buggy, only : buggy
implicit none
type(buggy) :: bug

bug = buggy(array=[1., 2., 3.], scalar=3)
call raise_bug(bug=bug, scalar=2)
stop
endprogram ifort_bug

I have imported many CVF projects, but yesterday I imported a project that is showing up in Visual Studio as a C project instead of a fortran project.  The import did produce a .vcxproj and .vfproj files along with the .sln file.  The project property pages are for C instead of fortran.  What did I do wrong?  Should I start over?

I have a requirement for a large .dll to be re-initialized.  (So, basically, all the SAVE variables, all the DATA variables, all the COMMON variables, need to be reset to their starting values).  I've been using the FreeLibrary() LoadLibrary() WinAPI functions for this purpose, but I've come across Thread Local Storage as an interesting alternative that would possibly work a little bit faster.  (We're not using OpenMP, just a single threaded .dll and its caller).  Is it possible to compile a Fortran .dll to default to Thread Local Storage?

Greetings,

my code is growing fat and I start having problems with label numbers. Do anybody know a tool to sequentially renumber the labels?

(disclaimer: I did a forum search, but I got only a few unrelated posts).

Thanks in advance.

I have just created a modified version of a program and selected win32 debug and done a clean build. I have added a break-point and selected start debugging.
The program starts, opens a console window, then stops at a READ statement and offers me to BREAK or CONTINUE.

EDIT ADDED LATER:

The problem was an end-of-file during reading of a file (the file was empty!). However, I was expecting to see the usual debug stuff to turn up, when I got the following behaviour. Is it normal?

When I select BREAK, it tells me that symbols are loaded but then that it could not find various PDB files.

'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded '\\space.rl.ac.uk\projects\Optics\Engineers\Tony Richards\Visual Studio 2005\Projects\multidiskdiffraction\OFFAXISDISKDIFFRACTION\OFFAXISDISKDIFFRACTION\Debug\OFFAXISDISKDIFFRACTION.exe'. Symbols loaded.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\ntdll.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\kernel32.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\KernelBase.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Program Files (x86)\Intel\Composer XE 2015\redist\ia32\compiler\libifcoremdd.dll'. Module was built without symbols.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Program Files (x86)\Intel\Composer XE 2015\redist\ia32\compiler\libmmd.dll'. Symbols loaded.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\imagehlp.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcrt.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\advapi32.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sechost.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\rpcrt4.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\sspicli.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\cryptbase.dll'. Cannot find or open the PDB file.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\msvcr110d.dll'. Symbols loaded.
'OFFAXISDISKDIFFRACTION.exe' (Win32): Loaded 'C:\Windows\SysWOW64\dbghelp.dll'. Cannot find or open the PDB file.
OFFAXISDISKDIFFRACTION.exe has triggered a breakpoint.

I have gone back to a debug version of a different solution and have been able to get that to properly start debugging.

 I have recently downloaded an update to the composer.

Since I am not allowed to attach the BUILD.HTM file for some reason, I am trying to attach it as a .TXT file. I cannot edit out the table cells below for some reason which appeared when I pasted in the build log earlier...

The following code produces an ICE with ifort 15.0 Build 20150407 (on Linux Intel(R) 64)

$ ifort -c testice.f90
testice.f90(50): warning #6178: The return value of this FUNCTION has not been defined.   [RES]
 elemental function met1(f) result(res)
-----------------------------------^
testice.f90(44): warning #6178: The return value of this FUNCTION has not been defined.   [RES]
 elemental function cnt_met1(f) result(res)
---------------------------------------^
testice.f90(38): warning #6843: A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value.   [Y]
 elemental subroutine to_ta(y,x)
----------------------------^
testice.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** 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 testice.f90 (code 1)

module m1
 implicit none

 type, abstract :: c_base
 contains
  private
  generic, public :: method => met1
  procedure(i_met1), pass(f), deferred :: met1
 end type c_base

 type, extends(c_base) :: t_cnt
 contains
  private
  procedure, pass(f) :: met1 => cnt_met1
 end type t_cnt

 type, extends(c_base) :: t_a
 contains
  private
  procedure, pass(f) :: met1
 end type t_a

 abstract interface
  elemental function i_met1(f) result(res)
   import :: c_base, t_cnt
   implicit none
   class(c_base), intent(in) :: f
   type(t_cnt) :: res
  end function i_met1
 end interface

 interface assignment(=)
   module procedure to_ta
 end interface

contains

 elemental subroutine to_ta(y,x)
  type(t_cnt), intent(in)  :: x
  type(t_a),  intent(out) :: y

 end subroutine to_ta

 elemental function cnt_met1(f) result(res)
  class(t_cnt), intent(in) :: f
  type(t_cnt) :: res

 end function cnt_met1

 elemental function met1(f) result(res)
  class(t_a), intent(in) :: f
  type(t_cnt) :: res

 end function met1

end module m1

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

module m2
 use m1
 implicit none

 type :: t_g
  type(t_a), allocatable :: aa(:,:), bb(:)
 end type t_g

contains

 subroutine s()

  integer :: i
  type(t_g) :: a

  allocate( a%aa(1,3), a%bb(3) )

  a%aa(1,:) = a%bb%method() ! ICE

  do i=1,3
    a%aa(1,i) = a%bb(i)%method() ! works
  enddo

 end subroutine s

end module m2

I'm sorry - I sent erroneously my message to Fortran/Windows forum, and repeat now. The Polyhedron Fortran benchmark is absent know,

and in particular is absent well known html:

http://www.polyhedron.com/compare0html

Do somebody have relative new (not too old) corresponding data ? I myself is sure that Intel Fortran benchmark results are the best, but I need this

data to prepare short information in our grant proposal.

Mikhail Kuzminsky

I am attempting to pass a C++ array of pointers into a Fortran subroutine.

The C++ array is of a structure, which exactly conforms to a Fortran derived type.

So in C++ I have pArray* c_arr[DIM1][DIM2];

Then I call a Fortran sub, passing in the C++ array of pointers like fortsub(c_arr[0][0])

In Fortran I have Subroutine fortsub (fort_arr) where I need fort_arr to be a container for the array of pointers.

I currently do not know how to make this work, I have something like:

Type (type1), Dimension(2,*), Target :: fort_arr where type1 is the same type as pArray.

Basically, my problem is I don't know how to pass a double dimensioned array of C++ structure pointers into a Fortran subroutine.

I know that he concept of "array of pointers" does not exist in Fortran and the way you have to do it is have an array of derived type with a pointer component, but I cannot seem to get the data passing on the argument list correct.

Anyone have some advice, perhaps with a specific example? I would appreciate it greatly. Thanks.

I have some old legacy code I'm trying to compile, which was originally compiled on the Lahey LF90 compiler. When I tried compiling using gfortran and then ifort, the program compiled but when running the program I got vastly different results. When I talked to the original author, he said he had to specify -vax while compiling in order to compile code which uses the DEC/VAX and IBM/VS extensions. Rewriting the code is not at all a good option, as the code is ridiculously long and I haven't found any good resources saying how to convert back to regular fortran 77. 

I've been trying to find what the equivalent option with ifort is, but all I've found is -Vaxlib (which doesn't appear to exist anymore?) or -vax which didn't work at all, or things saying that it should be done automatically, which obviously wasn't the case. So what do I need to do to compile this code? 

Any help would be greatly appreciated, thanks!

Users of numerical analysis packages such as those at www.netlib.org, especially the codes in the ACM TOMS group, often find themselves contending with Fortran 77 subroutines and functions that are now obsolete because those were replaced with intrinsics such as RADIX, EPSILON, HUGE, TINY, etc., in Fortran 90 and later. Although the proper fix is to rework the old code, replacing the add hoc pieces of code with RADIX, etc., that is not a chore that one wishes to undertake in every case -- often, we just want to build and run the old code with minimum effort.

Here is an example, where the user's purpose is defeated by the high quality of the IFort optimizer. I extracted a reproducer from www.netlib.org/toms, file 768.gz (TENSOLVE, a solver for simultaneous nonlinear equations). The test code is intended to output the floating point base (radix) of 2. With other compilers, and with /Od with IFort, it does. However, with /Ot or the default /fast, the program goes into an infinite loop, as did one of the test problem runs from TOMS-768 compiled with IFort.

      PROGRAM PBETA
      IMPLICIT NONE
      WRITE(*,*)'IBETA = ',IBETA()

      CONTAINS
      INTEGER FUNCTION IBETA()
C
C     returns radix(0d0)
C
      IMPLICIT NONE
      INTEGER ITEMP
      DOUBLE PRECISION A, B, TEMP, TEMP1
      DOUBLE PRECISION ZERO, ONE
      DATA ZERO, ONE/0.0D0, 1.0D0/

      A = ONE
      B = ONE
   10 CONTINUE
      A = A + A
      TEMP = A + ONE
      TEMP1 = TEMP - A
      IF (TEMP1-ONE .EQ. ZERO) GO TO 10
   20 CONTINUE
      B = B + B
      TEMP = A + B
      ITEMP = INT(TEMP-A)
      IF (ITEMP .EQ. 0) GO TO 20
      IBETA = ITEMP
      RETURN
      END FUNCTION
      END PROGRAM

The portion of the disassembly that corresponds to the lines from statement-10 to the IF statement four lines later is as follows. In effect, the optimizer replaces the IF statement before statement-20 with IF (0d0 .EQ. 0d0) GO TO 10. It similarly replaces lines 25 and 26 with, in effect, ITEMP = INT(B).

  00000076: 0F 28 CA           movaps      xmm1,xmm2     ; A=ONE
  00000079: 66 0F EF C0        pxor        xmm0,xmm0     ; should have been TEMP1 - ONE
  0000007D: 66 0F 2E C0        ucomisd     xmm0,xmm0     ; comparing 0D0 with 0D0
  00000081: F2 0F 58 C9        addsd       xmm1,xmm1     ; A=A+A
  00000085: 7A 02              jp          00000089      ; never happens
  00000087: 74 F4              je          0000007D      ; always true
  00000089: F2 0F 58 D2        addsd       xmm2,xmm2     ; B=B+B
  0000008D: F2 0F 2C C2        cvttsd2si   eax,xmm2

Lines 3 to 6 of the disassembly constitute the infinite loop. The loop is entered with xmm0 = 0 (from the PXOR), and xmm0 is never changed in the loop.

The compiler is allowed to make transformations and cannot be faulted based on standards-conformance. In fact, it could have continued its aggressive work and replaced the jp/je with an unconditional jmp.  Perhaps, it could have removed the ucomisd instruction, which is not needed any more. However, the compiler can, after optimizing the code, see that it has created an infinite loop, at which point it is probably worth issuing a warning to the unsuspecting user.

After all, when a program built from about 9000 lines of code "works" with competing compilers, hangs with IFort/default-options but works with IFort /Od, one may suspect a compiler bug. Nor is it trivial to locate the problem in the source code. What I did was to use the fsplit utility on the source files, and I then compiled all pieces with /Od for the base run. I then compiled each split file with /Ot, until I found the one that caused the infinite loop to occur.

Hi, I'm using intel fortran visual studio xe 2013 with visual studio 2012. I'm able to successfully compile my program, however I cannot start the debugging. It automatically exits with message: The program '[11156] ID.exe: Native' has exited with code 0 (0x0). How to solve this?

I wrote a simple and short program which ran well in debug mode. However, it went wrong in release mode. Values were assigned in an array, but they changed to some funny number when they were used.