David Muxworthy, ISO Fortran standards committee (WG5) Corrigenda editor and member of BCS (formerly British Computer Society) recently sent along a fascinating document. It comes from a project to digitize old papers from the archive of the BCS Fortran Specialist Group and is a 1977 summary of changes made to FORTRAN 77 as a result of the public comment review.

What's astonishing is the number of significant changes made to the language at this late stage in the standard's development. I knew about the change to PARAMETER, that resulted in DEC's VAX FORTRAN having to support both the form from the draft standard (without parentheses and type coming from the constant) and that of the final standard (with parentheses and the type coming from the identifier.) But I didn't know of many other last-minute changes and additions to the language, including:

• IF-THEN-ELSE
• IOSTAT
• .EQV. and .NEQV.
• Assumed-size arrays

and many more.

Also interesting was seeing the number of suggestions rejected for FORTRAN 77 that made their way into Fortran 90 and later standards, such as:

• Semicolon statement separators
• NAMELIST
• DOUBLE COMPLEX
• Requiring DO loop control variables to be INTEGER

It's a fun read, though as with many OCRed documents, there are uncorrected scanning errors.

I am fairly certain that we won't be seeing this level of flux after the comment period for Fortran 2015. (At least I hope not!)

I tried to used matlab to call fortran and run abaqus. I received the following error:

 
Error: A license for FCompW could not be obtained  
Your license has expired.  
  
License file(s) used were (in this order):  
    1.  Trusted Storage 
    2.  C:\Program Files (x86)\Common Files\Intel\Licenses\w_T2KZK3S4.lic 
    3.  C:\Program Files\Common Files\Intel\Licenses 
    4.  C:\PROGRA~2\Intel\COMPOS~2\bin\ia32\*.lic 
  
Please visit http://software.intel.com/sites/support/ to obtain license renewal information.  
 
ifort: error #10052: could not checkout FLEXlm license 
Abaqus Error: Problem during compilation - U_InputSahab.f 
Abaqus/Analysis exited with errors 

Anyone can help me resolve this issue? Thank you very much. 

I recently increased the size of some static array and now get the following warning.

I tried changing  my array to dynamic array for the file in question but to no avail.

Hi,

I'm using following derived type for an extended number representation:

    type :: XNT_TYPE_XNUM
        !(S)ignificant
        real(XNT_SK) :: s
        !(E)xponent
        integer(XNT_EK) :: e
    end type XNT_TYPE_XNUM

Somewhere I've declared the two variables:

    type(XNT_TYPE_XNUM), target :: ps(2,nl,nm)
    ...
    type(XNT_TYPE_XNUM) :: pt(2,nl,3)

When I do the assignment:

    pt(:,:,2)=ps(:,:,j)

the vectorization report says:

vector dependence: assumed ANTI dependence between PT line xxxx and  line xxxx

When writing instead:

    pt(:,:,2)%s=ps(:,:,j)%s
    pt(:,:,2)%e=ps(:,:,j)%e

then vectorization is possible but inefficient.

Can anybody tell me the reason why the compiler finds a dependence???

Thanks in advance!!

Hi,

I am trying to use a derived type structure in a dll subroutine using modules. Here is my main program:

Program Main
   
!dec$ attributes dllimport::_DERIVEDTYPECONSTRCT
   
use PARAM

   real a,b
   integer c

    a=2.0
    b=3.0
    c=6

    allocate (MyArray(1))
    call DERIVEDTYPECONSTRCT (1,a,b,c)!
   
     deallocate (MyArray)
end

the module "Param" is defined as below:

    MODULE PARAM
   
    type Derived_type
    real length  
    real width 
    integer measurmentflag
 
    end type Derived_type
   
    type(Derived_type), allocatable :: MyArray(:)
         
    END MODULE

The derived type "MyArray" is declared in the modules and is allocated in the Main program. I want to use is it a subroutine which is defined in a dll project.The subroutine DERIVEDTYPECONSTRCT is built as a dll:

subroutine derivedtypeConstrct (i,x,y,z)!
   
   
!dec$ attributes dllexport::derivedtypeConstrct
!DEC$ ATTRIBUTES STDCALL,ALIAS:"derivedtypeConstrct" :: derivedtypeConstrct
!DEC$ ATTRIBUTES REFERENCE  :: i,x,y,z
     
use PARAM
    integer i
    real x
    real y
    integer z

    MyArray(i)%length=x
    MyArray(i)%width=y
    MyArray(i)%measurmentflag=z
 
end

The problem is that when the code enters subroutine derivedtypeConstrct, the array "MyArray" becomes undefined although I have "use PARAM". The code works fine if "MyArray" is not allocatable or if subroutine derivedtypeConstrct is not a dll. I am trying to use the dll later in visual basic where MyArray will be a structure (I am not if it will work though).

Thanks for your helps.

Arash

This is probably a Visual Studio problem, but I'm hoping someone here knows something that might help.

Whenever I print source files (or at least selected lines) from Visual Studio (2010) I do not see the lines where I have set breakpoints.  They are just blank lines on the pages.  Same thing on multiple printers.

I thought maybe it had something to do with the "Fonts and Colors" settings in Options, but I don't see anything unusual there.

Please bear with me as my knowledge of programming is not very good.

My application written in Fortran via a C function calls and loads up a DLL/SO. Currently the source for the DLL/SO can be C or Fortran. When I write to stdout from the DLL/SO it does not write to the same stdout as my application. Going through the forums I understood that these possible solutions can be used.

1) Use the same run time libraries for both my application and the DLL/SO.

2) Use PROCEDURES with POINTERS (not supported in Fortran90)

Is there any other possible way for this to work?

Thanks for you help. Appreciate any suggestions/comments.

Hi,

I am using Intel Visual Fortran Compiler for windows.

It only provides  the single-, double-, and quadruple-precision numbers.

But I now need  to perform very accurate  calculations.

Is there any way to obtain, within the  Intel Visual Fortran for windows, 

the octuple- and even arbitrary-precision floating-point formats?

Thank you very much for your help!

Tie-Feng Fang

Hello, me again with my crusty old Compaq VF code. Further to my previous issue with files - https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/606997 - I have found that the code I am trying to upgrade from Compaq to Intel seems to be rather lax in opening and closing files. The problem may be compounded by the fact that the project I am working on compiles to well over 100 DLLs and for example with the issue linked above the FORT.1 is opened in one DLL but read in another, on entry to the second DLL the file appears to be closed. I got past that by explicitly opening it in the second DLL (bit of a hack but good enough for now). Then I hit another problem where a FORT.7 file is being written in one DLL without being explicitly opened and then a second DLL attempts to write to it and gets the error:

forrtl: severe (30): / process cannot access file because it is being used by another process

I have tried various things to fix this, e.g. explicitly opening and closing the file, the SHARED option, etc. and so far I have not found an appropriate combination but probably could eventually.

HOWEVER, I feel that if I fix that particular issue I would just find another one so I was wondering if there is an "I don't care about proper file handling" compiler flag that would make IVF behave like CVF did?

I also wonder if combining some or all of the DLLs into one DLL may get past some of these problems but since that is a fairly tedious task I would rather not start unless there was some certainty that it would work. One thing that makes me think it may not is that the DLLs are called by an executable built from PL/I so there will be a call to AAA.DLL which will return to PL/I then a call to BBB.DLL, AAA.DLL may have opened/written the file which is then accessed by BBB.DLL. Combining these into ABIG.DLL will still have two separate invocations of ABIG.DLL and so may suffer the same issues. Thoughts on this would also be appreciated.

I recently increased the size of some static array and now get the following warning.

I tried changing  my array to dynamic array for the file in question but to no avail.

My configuration is as follow:

vs2010

Intel(R) Visual Fortran Compiler XE 14.0.1.139 [Intel(R) 64].

I now got it in a state where even when compiling an empty file (no code or empty subroutine code) it also fires this warning.

Thanks and regards

http://www.bbc.co.uk/news/blogs-trending-35363394

Les

Greetings,

I can't seem too get the behavior I want in the following case.

I have an interface that looks like this:

      INTERFACE
        SUBROUTINE SUBA(PA_FP)
          REAL(4) PA_FP(:)
        END SUBROUTINE
      END INTERFACE

When I call that subroutine using a 1D Array, everything compiles and works fine.  However, if I have a 2D array and I call the subroutine as such:

REAL(4) ARRAY2D(10,20)

C Some code...

DO I = 1, 20
  CALL SUBA(ARRAY2D(1,I))
END DO

I get a compile error #6634: The shape matching rules of actual arguments and dummy arguments have been violated.
 

Clearly, the interface defines the parameter as a 1D array but by passing the parameter as I did above, I'm actually passing the address of a scalar.  So I tried calling it like this, instead:

REAL(4) ARRAY2D(10,20)

C Some code...

DO I = 1, 20
  CALL SUBA(ARRAY2D(:,I))
END DO

The compiler is now happy, but I'm not getting the expected behavior from within SUBA.  SUBA does not see the proper array content.

Note that without the interface definition, the first method works just fine.

So what's the proper way of calling SUBA in the case of a 2D Array, such that SUBA "sees" the 1D array only?

Steve?

(hey, it's always you ;) )

The web page is broken with respect to the navigation tree (near top). Shows as

Home > Forums > Forums

Sometimes the second "Forums" goes back a level, other times it logs you out.

Jim Dempsey

Hi,

I am using Windows 7 and trying to build a console application for Win XP (32) and got an error. 

Compiler i am using is Intel Fortran XE 14.0 compiler and Visual Studio 2012.

Also, in the Configuration Properties, i've set the Linker, System, SubSystem for "Console for Windows XP (/SUBSYSTEM:CONSOLE,"5.1")

The application built fine without any error.  It runs fine on Windows 7 but when i run the same application on Win XP, i get the following error:

Error:  Entry Point Not Found.

The procedure entry InitOnceExecuteOnce could not be located in the dynamic link library KERNEL32.DLL

Please help.

Thanks.

Ken

Hi

I was attempting to write a Fortran equivalent to the code provided in this vectorization tutorial

https://cvw.cac.cornell.edu/vector/exercise_1

My attempt at a Fortran vectorization equivalent is here:

#define ARRAY_SIZE 1024
#define NUMBER_OF_TRIALS 1000000

module array
    !dir$ attributes align:64 :: a, b, c
    double precision, dimension(ARRAY_SIZE) ::  a, b, c
end module

program main

    use array
    implicit none
    integer i, t

    double precision :: m = 1.0001

    ! Populate A and B arrays
    do i=1, ARRAY_SIZE
        b(i) = i
        a(i) = i + 1
    end do

    ! Perform an operation a number of times
    do t = 1, NUMBER_OF_TRIALS;
        do i = 1, ARRAY_SIZE
            c(i) = c(i) + m*a(i) + b(i)
        end do

        ! I have also tried a version with this line
        ! c = c + m * a  + b
    end do

end program

My questions(s):

0) Is this code as near-equivalent to the version 'simple.c' as in the link above?

1) Any further optimization recommendations?

2) The c version appears to always be faster, and I believe to be related to compound assignment (with '+=').  Here's some reasoning http://programmers.stackexchange.com/a/134136/69046

c[i] +=  m*a[i] + b[i];

Am I off base in thinking that this is the primary difference between the C and Fortran versions? 

Dear all,

I install gcc to my compiler directory:

~/compilers/gcc/gcc-5.3.0/bin/gcc

and I setup enviroment variables:

#-------------------------------------------------------------------------------

# GCC
#
export GCCVERSION=5.3.0
export GCCROOT=$HOME/compilers/gcc/gcc-$GCCVERSION
export LD_LIBRARY_PATH=$GCCROOT/lib64:$LD_LIBRARY_PATH
export C_INCLUDE_PATH=$GCCROOT/include/c++/$GCCVERSION:$C_INCLUDE_PATH
export C_INCLUDE_PATH=$HOME/compilers/gcc/source/gcc-5.3.0/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu:$C_INCLUDE_PATH
export INCLUDE=$HOME/compilers/gcc/source/gcc-5.3.0/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu:$INCLUDE
export PATH=$GCCROOT/bin:$PATH
#-------------------------------------------------------------------------------

export MPI_HOME=$HOME/program/mpich/mpich2-1.5-gfortran-$GCCVERSION

export PATH=$MPI_HOME/bin:$PATH
export INCLUDE=$MPI_HOME/include:$INCLUDE

But when I compile with ifort, it reported the following errors:

make[2]: Leaving directory `/home/user/program/zindo/zblas'
ifort -o zindo -traceback  -L./ control/zindo.o control/block1.o control/version.o control/libversion.o -Llib -lcontrol -lgeometry -lscf -lci -lspinorbit -lproperties -lclasic -lmndo -lgvb -llinear -llocalization -lsolvent -lmoments -linterfaces -lintegrals -lutil -lio -lalgebra -lzblas 
/home/user/compilers/gcc/gcc-5.3.0/bin/as: No such file or directory
/home/user/compilers/gcc/gcc-5.3.0/bin/ld: No such file or directory

However when I use "which" to locate the commad "as" and "ld", it can be found in the /usr/bin directory:

/usr/bin/as

/usr/bin/ld

Can anybody help me to solve this problem?

Hello, the example below produces two warnings #8450:

"The type/rank signature for this specific function and its arguments matches another specific function that shares the same OPERATOR generic binding.   [BINARY_OP_B]"
"The type/rank signature for this specific function and its arguments matches another specific function that shares the same OPERATOR generic binding.   [BINARY_OP_C]"

The warnings disappear, when the unitary operator binding (line 24) is commented out.
Is this a bug? Or am i doing something wrong?

Greetings
Wolf

Compiler: 15.5 and 16.1
 

module FOO
  implicit none

!=================================================================
  type, abstract :: ABSTRACT_TYPE
  contains

    procedure :: binary_op_A
    generic :: operator(.A.) => binary_op_A

    procedure :: binary_op_B
    generic :: operator(.B.) => binary_op_B

    procedure :: binary_op_C
    generic :: operator(.C.) => binary_op_C

  end type ABSTRACT_TYPE

!=================================================================
  type, extends (ABSTRACT_TYPE) :: EXTENDED_TYPE
  contains

    procedure :: unitary_op
    generic :: operator(.U.) => unitary_op !no warning without this line
    generic :: normiere => unitary_op

  end type EXTENDED_TYPE

!=================================================================
contains
!=================================================================

  elemental function unitary_op(rhs) result(res)
    class(EXTENDED_TYPE), intent(in   ) :: rhs
    type(EXTENDED_TYPE)                 :: res
  end function unitary_op

  elemental function binary_op_A(lhs, rhs) result(res)
    class(ABSTRACT_TYPE), intent(in   ) :: lhs, rhs
    real                                :: res
  end function binary_op_A

  elemental function binary_op_B(lhs, rhs) result(res)
    class(ABSTRACT_TYPE), intent(in   ) :: lhs, rhs
    type(EXTENDED_TYPE)                 :: res
  end function binary_op_B

  elemental function binary_op_C(lhs, rhs) result(res)
    class(ABSTRACT_TYPE), intent(in   ) :: lhs, rhs
    real                                :: res
  end function binary_op_C

!=================================================================
end module FOO

Hello, i get those two warning messages, when compiling the code below.

"(22) warning #6706: There is a mixture of specific functions and specific subroutines for one generic-spec.   [INTF_SETARRAY]"
"(28) warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [INTF_GETSCALAR]"

I do not understand, what is wrong with those declarations. This contruct seems to work fine in my real code, but the warnings confused me.

Greetings
Wolf

Compiler: 15.5 and 16.1

module FOO
  implicit none

!=================================================================
  type, abstract :: ABSTRACT_TYPE
  contains

    procedure(intf_getArray),  deferred :: getArray
    procedure(intf_setArray),  deferred :: setArray
    procedure(intf_getScalar), deferred :: getScalar
    procedure(intf_setScalar), deferred :: setScalar

  end type ABSTRACT_TYPE

!=================================================================
  interface abstract
    real pure function intf_getArray(this) result(res)
      import :: ABSTRACT_TYPE
      class(ABSTRACT_TYPE), intent(in   ) :: this
    end function

    pure subroutine intf_setArray(this, inp)
      import :: ABSTRACT_TYPE
      class(ABSTRACT_TYPE), intent(inout) :: this
      real,                 intent(in   ) :: inp(3)
    end subroutine

    real elemental function intf_getScalar(this) result(laenge)
      import :: ABSTRACT_TYPE
      class(ABSTRACT_TYPE), intent(in   ) :: this
    end function

    elemental subroutine intf_setScalar(this, inp)
      import :: ABSTRACT_TYPE
      class(ABSTRACT_TYPE), intent(inout) :: this
      real,                 intent(in   ) :: inp
    end subroutine
  end interface

!=================================================================
  type, extends (ABSTRACT_TYPE) :: EXTENDED_TYPE
  contains
    procedure :: getArray     => getArray_Extended
    procedure :: getScalar    => getScalar_Extended
    procedure :: setArray     => setArray_Extended
    procedure :: setScalar    => setScalar_Extended

  end type EXTENDED_TYPE

!=================================================================
contains
!=================================================================


  pure function getArray_Extended(this) result(res)
    class(EXTENDED_TYPE), intent(in   ) :: this
    real                                :: res
  end function

  real elemental function getScalar_Extended(this)
    class(EXTENDED_TYPE), intent(in   ) :: this
  end function

  pure subroutine setArray_Extended(this, inp)
    class(EXTENDED_TYPE), intent(inout) :: this
    real,                 intent(in   ) :: inp(3)
  end subroutine

  elemental subroutine setScalar_Extended(this, inp)
    class(EXTENDED_TYPE), intent(inout) :: this
    real,                 intent(in   ) :: inp
  end subroutine setScalar_Extended

!=================================================================
end module FOO