The Intel Parallel Studio XE 2018 (IPSXE2018) Update 2 has been released together with the Intel compiler 18.0.2. This version of Intel compiler provides the fix for Spectre variant 2. Please refer to this article for more information -  https://software.intel.com/en-us/articles/using-intel-compilers-to-mitigate-speculative-execution-side-channel-issues.

We will keep you posted when any additional fixes will be available.

I have the following subroutine:

recursive subroutine GetVoltage(cell, rlp, verbose)

!DEC$ ATTRIBUTES DLLEXPORT :: GetVoltage
 

use io
 

IMPLICIT NONE
 

type(unitcell),pointer :: cell

type(gnode),INTENT(INOUT) :: rlp

logical,INTENT(IN),OPTIONAL :: verbose

real(kind=sgl) :: io_real(1)
 

call ReadValue('Enter the microscope accelerating voltage [kV, R] : ', io_real, 1)

cell%voltage = dble(io_real(1))

call CalcWaveLength(cell,rlp,verbose=.TRUE.)

end subroutine

and when that code hits, what ever number I enter on the command prompt (200.0 in my case) the cell%voltage value is 0.0. Now if I change the subroutine slight to put in the following code:

recursive subroutine GetVoltage(cell, rlp, verbose)

!DEC$ ATTRIBUTES DLLEXPORT :: GetVoltage
 

use io
 

IMPLICIT NONE
 

type(unitcell),pointer :: cell

type(gnode),INTENT(INOUT) :: rlp

logical,INTENT(IN),OPTIONAL :: verbose

real(kind=sgl) :: io_real(1)
 

call ReadValue('Enter the microscope accelerating voltage [kV, R] : ', io_real, 1)

cell%voltage = dble(io_real(1))
 

if (present(verbose)) then

if (verbose) then

write (*,*) 'cell%voltage : ', cell%voltage

end if

end if

call CalcWaveLength(cell,rlp,verbose=.TRUE.)

end subroutine

The the "200.0" value is parsed correctly. This is with Version 17 update 6 on VS2015 on Windows 10. I have not tried version 18 yet. Anybody have any ideas on why this might be happening?

Thanks

Mike Jackson

The following OpenMP directives in Intel Visual Fortran worked fine in version 2016 (16.0.4.246) but causes an error in 2017 (17.0.6.270)

                     !$omp parallel do default(none) if (parallel .and. nbsubnet>1) &

The error in version 2017 is:

error #5082: Syntax error, found '.AND.' when expecting one of: :

It would appear that the 2017 version of Intel's Fortran compiler no longer accepts .and. and yet the list of what it expects is empty. I have not tried this in the 2018 version. I believe the logic .and. should be accepted.

Thank you,

Lester

Dear All:

We are getting some really interesting results from bridge monitoring for vibration - particularly at higher frequencies.  We are starting to look at second order effects to explain some of the scatter in the results.

The standard structural analysis uses a first order analysis and does not allow for sway etc..  I found a neat little program in the 1973 Harrison book that does a second oder analysis.  A version of the program running on VS 2017 and latest Intel Fortran is attached. 

I have not seen this solution method for matrix inversion before, maybe I am missing something, but has anyone seen this solution technique before.  Harrison published the book whilst he was at Sydney University in Australia, but he appears to have done the bulk of the work in the USA at Lehigh Uni - a big steel place  in the late 1960s. I include the program notes.  He does not explain the technique and it is different to his other programs that appear more traditional linear algebra. 

My program is effectively the Harrison code with minimal changes to make it run, but the arithmetic ifs etc have not yet been cleaned out. 

I would aim to pull out Harrison's solver, make it 3D and then use Pardiso and then Feast. 

John

The following code does not yield the correct result with openmp enabled (version 18.0.1.156). Bug?

program test
    implicit none
    real	:: val
    
    call sumarray(10,val)
    print *,val

    contains 
        
    subroutine sumarray(n,val)
        real	:: y(n),val
        integer	:: n,i
            
        y=0.0
!$omp parallel do reduction(+:y)		
        do i=1,100
            y(mod(i,n)+1)=y(mod(i,n)+1)+1
        enddo
        val=sum(y)
    end subroutine
end program

Hi, I‘ve encountered a derived-type constructor selection issue and the compiler reported an error which seemed non-relevant. The sample code is as follows:

module test
    implicit none
    
    private
    public :: var

    type :: tp
        private
        integer(8) :: var1
        logical    :: var2 = .false.
    end type tp
    
    interface tp
        module procedure :: init
    end interface tp
    
    interface
        module function init(var)
            type(tp)            :: init
            integer, intent(in) :: var
        end function init
    end interface

    integer(8), parameter :: default = 10
    type(tp),   parameter :: var     = tp(default, .false.)
   
end module test

The error message is:

error #6050: This parameter was defined too late.   [DEFAULT]

If tp and init interfaces are removed, the code can be compiled with no errors. Appreciate any help.

I want to import a subroutine defined in a dll I built into Delphi in my fortran code.
How can I tell the compiler that I do not want the underline prefixes when using the dllimport command?

For now I have something like:

! Dec $ attribute dllimport :: myfunc

and I specify in visual studio environment that I am using standard calls and names with uppercase. However, the compiler always adds an underscore prefix and throws an error when linking because it can not find the icon outside _MYFUNC (the name of the subroutine is MYFUNC in the dll and the associated lib file)

https://www.google.com.vn/

I have an old IVF VS Solution that uses the F90 GLUT library. This solution compiled correctly (without errors) using an older version of IVF.

IVF V17 u 5 performs stronger interface checking.

One of the function calls to the GLUT library specifies a callback function to handle keyboard input. The official interface in the GLUT library has the interface for the callback function declared with its 3 arguments attributed with INTENT(INOUT). The interface, and keyboard function I wrote mistakenly used INTENT(IN), as the function does not "cook" the arguments (and the C function library passes these by value and cannot be changed). The older version of IVF did not complain about the mismatch between INTENT(IN) and INTENT(INOUT).

I am not complaining about the compiler complaining about about the mismatch between INTENT(IN) and INTENT(INOUT)...
I am complaining that the error message simply states the arguments (interface) are (is) incorrect with no additional information as to why it is complaining (in this case, correct argument types with differing INTENT). It would have saved me considerable amount of time in diagnosing and correcting the problem. (The first argument in the C interface is unsigned char, but the Fortran uses GLcint)

Jim Dempsey

Hello all, 

I have written simple fortran code in visual studio. But when I run it in Visual studio with Intel fortran compiler: I am getting following error message:

Unable to start the program:

'C:Users\...\..Console4\Debug\Console4.exe 

Access is denied. 

Code is built successfully though. Here is a log for that:

1>------ Build started: Project: Console4, Configuration: Debug Win32 ------
1>Linking...
1>Embedding manifest...
1>
1>Build log written to  "file://C:\Users\...\Desktop\...\Console4\Console4\Debug\BuildLog.htm"
1>Console4 - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Can anybody please help me to fix this issue? We are unable to determine where is this error message is coming from. 

Thank you in advance for your help in this matter, 

Nik

I have recently noticed that when I have a derived type with a "final" procedure, and I am debugging line by line with F11, when the instance of the derived type moves out of scope at the relevant "end subroutine" statement, the debugger just jumps to the next statement after the original "call", when I would really like it to (i.e. expect it to) jump to the first statement in the final procedure.

Now that I know this is what will happen I can put a break point in the final procedure, and that does work, but I do wonder if this is a "feature" of debugging that has been overlooked, or at least not documented very well.

Last year I discussed the very same problem here... 

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/713372

This year a different computer presents the same error but doesn't respond to the .NET 4.5.2 fix.

Running the Visual Studio installer separately reports

Microsoft Visual Stuiod 2013 Shell (Minimum) Interop

Assemblies
Fatal Error During Installation

The log is quite lengthly. Two error messages toward the end report

Error Message: An error occurred during the installation of assemly ENDTE90a, version "9.0.0.0", blah blah

Error Message: One or more files required to restore your computer to its previous state could not be found. Restoration will not be possible.

Is that enough to be helpful, or should I attempt to attach the entire log?

Fyi to readers on a support incident submitted at the Intel Online Service Center: Intel Fortran compiler 18.0 Update 2 generates an invalid error for the following code involving a generic interface to a subprogram with the MODULE keyword.

C:\Temp>type m.f90
module m
   interface
      module subroutine sub()
      end subroutine sub
   end interface
   interface genfoo
      module subroutine foo( k )
         integer, intent(in) :: k(:)
      end subroutine
   end interface
end module
submodule(m) sm
contains
   module subroutine sub()
      integer :: k(1)
      call genfoo( k )
   end subroutine sub
   module subroutine foo( k )
      integer, intent(in) :: k(:)
      print *, k
   end subroutine foo
end submodule

C:\Temp>ifort /standard-semantics /warn:all /stand m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 18.0.2.185 Build 20180210
Copyright (C) 1985-2018 Intel Corporation.  All rights reserved.

m.f90(16): error #6285: There is no matching specific subroutine for this generi
c subroutine call.   [GENFOO]
      call genfoo( k )
-----------^
compilation aborted for m.f90 (code 1)

C:\Temp>

Hello,

I’m getting an error, which is really strange and i don’t understand why.
I have attached a reduced version, so that only the relevant code lines are included. I have also attached a screenshot of the error message.

I’m using the intel fortran compiler: 12.1.4.325 Build 20120410 with the Microsoft visual studio 2010.
The compile flags: ifort /debug:full /Zi /Od /traceback /free /w /check:all MultivariateInterpolatorIDW.for

I have found some modifications, which don’t cause an error, but it makes no sense to me, that the attached one is not working. I hope someone can explain it to me. Do i violate a fortran specification without knowing? Thank you for reading.

Modification which are fine
delete the keyword: target
OR
Change
integer( kind=i18 ), intent(inout), target :: axisIntervalIds(:)  to
integer( kind=i18 ), intent(in), target :: axisIntervalIds(:)
OR
Change
integer( kind=i18 ), intent(in) :: axisDataPointIntervalId(:) to
integer( kind=i18 ), intent(in) :: axisDataPointIntervalId(12)
OR
Change the line to

weights( 1:12:2 ) = dataPerAxis( axisDataPointIntervalId( 1:12:2 ) - 1 + axisIntervalIds( 2:12:2 ) ) to

test(:) = axisDataPointIntervalId( 1:12:2 ) - 1 + axisIntervalIds( 2:12:2 )
weights( 1:12:2 ) = dataPerAxis(test)

      module MultivariateInterpolatorIDW

        implicit none
        private

        integer, parameter :: r15 = SELECTED_REAL_KIND( 15, 307 )
        integer, parameter :: i18 = SELECTED_INT_KIND( 18 )

        public :: MVI_interpolate

      contains

        subroutine MVI_interpolate()

          real( kind=r15 ) :: interpolatedValueV(1)
! local
          real( kind=r15 ) :: dataPerAxis(12)
          integer( kind=i18 ) :: axisDataPointIntervalId(12)
          integer( kind=i18 ), target :: axisIntervalIds(12)


          dataPerAxis(:) = 10
          axisDataPointIntervalId( : ) = 1
          axisIntervalIds(:) = 1

            interpolatedValueV( 1 ) = MVI_interpolateSub( dataPerAxis, axisDataPointIntervalId, axisIntervalIds )

        end subroutine


        function MVI_interpolateSub( dataPerAxis, axisDataPointIntervalId, axisIntervalIds )

! in
          real( kind=r15 ), intent(in) :: dataPerAxis(12)
          integer( kind=i18 ), intent(in) :: axisDataPointIntervalId(:)
! inout
          integer( kind=i18 ), intent(inout), target :: axisIntervalIds(:)
! return
          real( kind=r15 ) :: MVI_interpolateSub
! local
          real( kind=r15 ) :: weights(12)

          weights( 1:12:2 ) = dataPerAxis( axisDataPointIntervalId( 1:12:2 ) - 1 + axisIntervalIds( 2:12:2 ) )

           MVI_interpolateSub = 0.0

        end function

      end module

      program main

        use MultivariateInterpolatorIDW

        implicit none

        call MVI_interpolate( )

      end program

A legacy program compiled with IVF Composer XE 2013 SP1 Update 3 Integration for Microsoft Visual Studio* 2010, 14.0.0092.2010, uses the Fortran Portability Function ACCESS(name,mode) to test whether a user has network access to a particular license file.  Access is granted by assigning the user to an Active Directory Group that has read access. 

The ACCESS call uses the mode as "r", which is supposed to test for read permission.  It works fine on Windows 7, but after a recent OS-only update, in Windows 10 ACCESS() is now returning " EINVAL", which is supposed to mean "The mode argument in invalid".  Apparently, the hard-coded "r" is not getting included in the call.  A second or third execution of the program within a few minutes will work properly without encountering this error.

Does anyone know if this is a problem with Windows or with IVF?  Any suggestions on getting past this would be very welcome.

Thanks very much, and God bless!

Jack

When I try to compile the following submodule, I get the following remark from ifort that the result variable has not been used:

..\src\mod_Calculus@Gradient.f90(12): remark #7712: This variable has not been used.   [GRADCOMPLEXSTEP]
  module function GetGradComplexStep(GetCplxFunc,nd,Delta,Point) result(GradComplexStep)
------------------------------------------------------------------------^

clearly, this is a wrong remark as the result variable is indeed used in the body of the code. Why does the compiler issue such a remark?

submodule (Calculus) Gradient

  use Constants, only: IK, RK
  implicit none

contains

  ! Compute the first derivative using the complex-step method.
  module function GetGradComplexStep(GetCplxFunc,nd,Delta,Point) result(GradComplexStep)
    use Constants, only: IK, RK
    implicit none
    procedure(GetCplxFuncProc) :: GetCplxFunc
    integer(IK), intent(in)    :: nd
    real(RK)   , intent(in)    :: Delta(nd)
    real(RK)   , intent(in)    :: Point(nd)
    real(RK)                   :: GradComplexStep(nd)
    complex(RK)                :: PointComplex(nd)
    integer(IK)                :: i
    PointComplex = Point
    do i = 1, nd
      PointComplex(i) = cmplx( Point(i) , Delta(i) , kind=RK )
      GradComplexStep(i) = aimag( GetCplxFunc( nd , PointComplex ) ) / Delta(i)
      PointComplex(i) = cmplx( Point(i) , 0._RK , kind=RK )
    end do
  end function GetGradComplexStep

end submodule Gradient

Noticed some unexpected behaviour with breakpoints

During a debug run, I removed some break points.

At the end of the run, and/or when I reload the project the break points are back again.

Any reason why the break point changes are ignored?

I'm writing a hashing function using unsigned 32 bit integers, however I'm not sure if it can be written/printed? Haven't seen any documentation

What's the best method to write/print a c_int32_t integer in fortran ? In C printf would use PRIu32

Hello,

since IFORT 18 Update 2 i get an error when i try to use custom constructors on derived type constants. In the following example it throws two errors in Line 14:
error #6259: This array or function or substring is invalid in constant expressions.   [CONSTRUCTOR3X1]
error #7715: Replacing invalid structure constructor by integer 1.   [<NULL_STRING>]

Code:

module M_MODULE
  use, intrinsic :: iso_fortran_env, only: DP => real64


  type, public :: T_VEC
    real(DP), public :: vec(1:3) = [0.0_DP,0.0_DP,0.0_DP]
  end type T_VEC

  interface T_VEC
    module procedure constructor3x1
    module procedure constructorXYZ
  end interface T_VEC

  type(T_VEC), parameter, public :: E_X = T_VEC([1.0_DP,0.0_DP,0.0_DP])
  type(T_VEC), parameter, public :: E_0 = T_VEC()

contains

  pure function constructor3x1(array) result(new_vec)
    real(DP), intent(in) :: array(3)
    type(T_VEC) :: new_vec

    new_vec%vec = array

  end function constructor3x1

  elemental function constructorXYZ(x, y, z) result(new_vec)
    real(DP), intent(in) :: x,y,z
    type(T_VEC) :: new_vec

    new_vec%vec(1) = x
    new_vec%vec(2) = y
    new_vec%vec(3) = z

  end function constructorXYZ

end module M_MODULE

This worked as intendet since Version 16 i think. I was not able to find a workaround so far, as an initialization of a variable with this constructor does not work, too.

I tried to replace line 14 with

type(T_VEC), parameter, public :: E_X = transfer([1.0_DP,0.0_DP,0.0_DP], T_VEC())

This compiles in the example, but fails in my project with an ICE. And i did not try, if it works as intendet.

Is this a compiler bug or is this usage of an user defined constructor not allowed?

Greetings

Wolf

Hello Everyone,

I have written many Fortran DLL's for Excel VBA, but this one has me really stuck. Fortran version 11.1  using MSVS 2008; Excel 2007 VBA running on Windows 10  (Excel is 32-bit version)

My DLL performs two different tasks

1. Given an acceleration time history (maybe 5-6000 points) compute velocity, and displacement

2. Given the same acceleration time history, computes an earthquake response spectrum via Duhamel's integral. 

Both of these I have done many times in Fortran, and in VBA. And I have used Fortran DLL's before to do this. 

Fortran DLL important parts are shown below

     
Subroutine AVD(Accel,Vel,Disp,VMax,DMax,Gravity,DeltaT,NumAcc)
CDEC$ ATTRIBUTES DLLEXPORT, STDCALL, REFERENCE, ALIAS: "AVD" :: AVD
        
      INTEGER*4, INTENT (IN) ::NumAcc
	REAL, INTENT(IN) ::  Accel(20000),Gravity,DeltaT
	REAL, INTENT(OUT) :: Vel(20000),Disp(20000),VMax,DMax

	factor=Gravity*DeltaT/2.0
	factor2=DeltaT/2.0
	Vel(1)=0.0
	Disp(1)=0.0
	do 10 i=2,Numacc
	  Vel(i)=  etc....


 Subroutine EQSpectra(Accel,Xomega,Period,DisMax,VelMax, 
     !                     AccelMax,Zeta,DeltaT,NumAcc,MaxPts)
CDEC$ ATTRIBUTES DLLEXPORT, STDCALL, REFERENCE, ALIAS: "EQSpectra" :: EQSpectra
      
      INTEGER*4, INTENT(IN) :: NumAcc,MaxPts
      REAL, INTENT(IN) ::  Accel(20000),Zeta(3),DeltaT
      REAL, INTENT(OUT) :: Xomega(201),Period(201)
	Real, Intent(out) :: DisMax(3,201),VelMax(3,201)
	Real, Intent(out) :: AccelMax(3,201)
       NAccDim =20000
       NumPts=NumAcc*2  
      if (NumPts .gt. MaxPts) then
         NumPts = MaxPts
       end if    etc.......

The VBA code looks like so

Declare Sub EQSpectra Lib "I:\FortranSubs\spectra2018.dll" (Accel As Single, Xomega As Single, _
        Period As Single, DisMax As Single, VelMax As Single, _
        AccelMax As Single, Zeta As Single, DeltaT As Single, _
        NumAcc As Long, MaxPts As Long)

Declare Sub AVD Lib "I:\FortranSubs\spectra2018.dll" (Accel As Single, Vel As Single, Disp As Single, _
        Vel1Max As Single, Disp1Max As Single, Gravity As Single, DeltaT As Single, NumAcc As Long)

.....then later in the VBA, I call the respective routines

'compute Velocity, Displacement and write them in
Call AVD(Accel(1), Vel(1), Disp(1), Vel1Max, Disp1Max, Gravity, DeltaT, NumAcc)
For i = 1 To NumAcc
  ActiveSheet.Cells(5 + i, 1) = DeltaT * (i - 1)
  ActiveSheet.Cells(5 + i, 3) = Accel(i)
  ActiveSheet.Cells(5 + i, 4) = Vel(i)
  ActiveSheet.Cells(5 + i, 5) = Disp(i)
Next i

and later, the call to compute spectra....

Zeta(1) = 0#
Zeta(2) = 0.02
Zeta(3) = 0.05
Call EQSpectra(Accel(1), Xomega(1), Period(1), DisMax(1, 1), VelMax(1, 1), AccelMax(1, 1), _
     Zeta(1), DeltaT, NumAcc, MaxPts)

I have been able to successfully run the VBA program past the call to AVD and plot the results on the spreadsheet, however, when I call the EQSpectra routine I get:   Run-time error  '453'

Can't find DLL entry point EQSpectra in I:\FortranSubs\spectra2018.dll

It is obviously finding spectra2018.dll since the AVD routine runs successfully. If anyone has a brilliant suggestion let me know. If not, I will break the routine down to a more simple one and hopefully get it to work correctly, then slowly build it back up again.

Thanks

Hi,

I am trying a code to use fortran quadpack library functions for integration. For this reason I download quadpack from:

http://people.sc.fsu.edu/~jburkardt/f77_src/quadpack/quadpack.html

and modified it by converting to a module file. When I run the program the following linking errors occures:

Severity

Code

Description

Project

File

Line

Error

error LNK2019: unresolved external symbol _QWGTC referenced in function _QUADPACK_mp_QC25C

quadpack.obj

Would you please direct me how can I solve the problem?

Please accept my kind thanks in advance.