Linking to a net version of the documentation just does not work.

How do we get Intel to listen to us, and understand that we want the Compiler Documentation and Language Reference integrated into MSVS.

Trying to locate documents through multiple hyperlinks, with network latency, adds minutes to what should be a 20 second lookup at the most.

You are seriously affecting our productivity by not providing local versions of the documentation integrated into MSVS.

We want a system that works for us.

Thank you,

David White

Hi,

while moving from IFORT 18.0 to 18.1 i got a linking problem with submodules. The following Code produces a linker error LNK2019 "Unresolved external symbol "FOO" in function "MOD_A_mp_SOME_ROUTINE".

module MOD_A

  type, public :: BAR_TYPE
    contains
      procedure, nopass :: foo    => special_foo
  end type BAR_TYPE

  interface
    module subroutine special_foo()
      !DEC$ ATTRIBUTES DLLEXPORT :: special_foo
    end subroutine special_foo
  end interface

contains

  subroutine some_routine()
    !DEC$ ATTRIBUTES DLLEXPORT :: some_routine
    type(BAR_TYPE) :: bar
    call bar%foo()
  end subroutine some_routine

end module MOD_A


submodule(MOD_A) MOD_A_S_GERADE
contains
  module subroutine special_foo()
    !DEC$ ATTRIBUTES DLLEXPORT :: special_foo
  end subroutine special_foo
end submodule MOD_A_S_GERADE

This worked in previous compiler versions. It works without the submodule:

module MOD_A

  type, public :: BAR_TYPE
    contains
      procedure, nopass :: foo    => special_foo
  end type BAR_TYPE

contains

  subroutine special_foo()
    !DEC$ ATTRIBUTES DLLEXPORT :: special_foo
  end subroutine special_foo

  subroutine some_routine()
    !DEC$ ATTRIBUTES DLLEXPORT :: some_routine
    type(BAR_TYPE) :: bar
    call bar%foo()
  end subroutine some_routine

end module MOD_A

Greetings

Wolf

A client is running w_fcompxe_redist_ia32_2013.5.198.msi and it is failing to install any files.  Any clues to what his problem could be?

I have a module that includes some abstract interfaces. These interfaces use derived types from different modules, and I import these in the abstract interface by an "import" statement of the derived type in question, with the module the derived type is contained in being "use"d in the module itself. This compiles fine on gfortran, but with Intel Fortran 18, I get a "This derived type name has not been declared" error, and I can't figure out why. The module in question is below, and the derived type that throws the error is the "Result" derived type from the "ResultModule" module:

module spcEstuaryReach
    use ResultModule
    implicit none

    type, public, abstract :: EstuaryReach

      contains
        procedure(createEstuaryReach), deferred :: create
        procedure(updateEstuaryReach), deferred :: update
    end type

    abstract interface
        function createEstuaryReach(me) result(r)
            import EstuaryReach, Result
            class(EstuaryReach) :: me
            type(Result) :: r
        end function

        function updateEstuaryReach(me, t) result(r)
            import EstuaryReach, Result
            class(EstuaryReach) :: me
            integer :: t
            type(Result) :: r
        end function

    end interface


end module

Fyi on a support requested at the Intel OSC:

module m

   interface
      module subroutine sub( s )
         !dir$ attributes stdcall, reference, mixed_str_len_arg :: sub
         !dir$ attributes decorate, alias:'sub' :: sub

         character(len=*), intent(in) :: s

      end subroutine sub

   end interface

end module

submodule(m) sm

contains

   module subroutine sub( s )
      !dir$ attributes stdcall, reference, mixed_str_len_arg :: sub
      !dir$ attributes decorate, alias:'sub' :: sub

      character(len=*), intent(in) :: s

      print *, s

   end subroutine sub

end submodule

and the compilation response:

C:\temp>ifort /c /standard-semantics /warn:all m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R
) 64, Version 18.0.1.156 Build 20171018
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.

m.f90(21): error #7281: This symbol has multiply declared DEC$ ATTRIBUTES REFERE
NCE{32|64] attribute. [SUB]
!dir$ attributes stdcall, reference, mixed_str_len_arg :: sub
-------------------------------------------------------------^
compilation aborted for m.f90 (code 1)

I think the above shown error #7281: This symbol has multiply declared DEC$ ATTRIBUTES REFERENCE{32|64] attribute. [SUB] should not occur.  The listed attributes in the SUBMODULE with the module subroutine sub are the same as those in the ancestor module.   I believe Intel Fortran should be able to support this.

I have requested a fix for this issue.

I'd appreciate some guidance from those who have had a better perspective on changes in OpenGL over the last decade or so.  I have a number of legacy Fortran programs that make use of OpenGL.  I know Fortran well, but the developer of the basic connections to OpenGL is no longer around.  It appears that he used f90gl/glut to create the basic graphics that we needed.

We were able to compile using old compilers and the techniques this fellow used up until early 2017 when the powers that be felt that we needed to update software.  This obliterated our ability to compile and use these olds ways to connect to OpenGL.  So it falls to me as the one with the most grey in my beard to figure out how to re-enable our ability to modify these programs with OpenGL.

After a year of fussing, I now have at least "Intel Parallel Studio XE 2018 Update 1 Composer Edition for Fortran Windows" and am able to compile.  That was not a small effort.  But now I press forward to OpenGL.  

I'm gathering that GLUT is no longer a realistic/modern bridge between Fortran and OpenGL.  I've certainly reviewed the samples Intel provides with Parallel Studio, though it looks pretty foreign to my eyes.  I'd welcome some advice on how to approach a new "bridge" or what I need to learn to implement OpenGL with these old programs. 

I did begin some tutorials at learnopengl.com, but this takes a route of GLFW/GLAD that seems more complex than what I need.  Do I just need to push through it?

Thanks for helping the old dog learn new tricks.

I recently installed visual studio 2013 and Fortran compiller 2016 S4 student version on my laptop. Unfortunately with my laptop I cant compile the same Fortran code that I can compile with Fortran compiller 2005 and visual studio 10 on my PC. I am quite sure the Fortran and visual studio are coupled on my laptop. But still don't know what cause this issue. Any help will be greatly appreciated. 

Dear all,

     i realized that there are several post regarding my issues, but i couldnt fix the issue based the available thread. So i tried to install community 2017, 2015 and even professional 2015 and then for the PSXE i tried the PSXE 2018 up 1, PSXE 2017 Up 4,  PSXE 2016 up 4, and PSXE 2016 initial. All of the try and combination i tried is failed with the same issue msvcrt_x64.msi. All of this issue began when i resetting my pc. and after i reset it again the issue still persist. Kindly give me some suggestions guys.

Thanks you so much

Hello friends!

I am receiving a warning message of overflow(see attached) when trying to convert character to real.

This is the simple piece of code 

character*4 nLevels

real*4 num_nlevels

        write (nlevels, '(I0)') num_nlevels

Thanks.

Regards.

Hello,

I have some difficulties to point from a Superclass to a Subclass Object. tElement is the Superclass and tBeam is the Subclass.

TYPE(tBeam),				ALLOCATABLE, TARGET	:: beams(:)
CLASS(tElement),			POINTER	:: element
CLASS(tElement),			POINTER	:: elements(:)

ALLOCATE(beams(1:10))

It works for a single Object...:

ALLOCATE(Element, SOURCE = beams(1), STAT = ierror)

... but for an array it seems to work because ierror is 0, but in Visual Studio he shows me "undefined pointer/array"

ALLOCATE(Elements, SOURCE = beams, STAT = ierror)

is this a Visual Studio Bug or am I doing something wrong?

MODULE mElement
	IMPLICIT NONE

	PRIVATE
	PUBLIC :: tElement

	TYPE :: tElement
		INTEGER(4) :: element_property = 1234
	END TYPE tElement
END MODULE mElement

MODULE mBeam
	USE mElement
	IMPLICIT NONE

	TYPE, EXTENDS(tElement) :: tBeam
		INTEGER(4) :: beam_property = 5678
	END TYPE tBeam
END MODULE mBeam


PROGRAM TEST
	USE mBeam
	USE mElement
	IMPLICIT NONE

	TYPE(tBeam),				ALLOCATABLE, TARGET	:: beams(:)
	CLASS(tElement),			POINTER	:: element
	CLASS(tElement),			POINTER	:: elements(:)
	INTEGER(4)							:: ierror
	INTEGER(4)							:: element_property, beam_property

	ALLOCATE(beams(1:10))
	ALLOCATE(Element, SOURCE = beams(1), STAT = ierror)
	IF (ierror .EQ. 0) && element_property = Element%element_property

	ALLOCATE(Elements, SOURCE = beams, STAT = ierror)
	IF (ierror .EQ. 0) && element_property = Elements(3)%element_property
END PROGRAM TEST

When I install the parallel studio xe 2018, it warns me that "some processes block installation. Exit blocking software and click Re-check below to validate status or click Next to close blocking processes automatically. " And below is almost all my processes running in my system including system processes. And if I continue installing, it begin "prepare environment" and the screen turns black, and my computer restart automatically.

Is there anyone have the same problem or who knows how to solve it? My software is the student version so I have to ask for help here.

Hello, 

I am working on the old F77 code which I have to combine with the newer version of software. I have the question about multidimensional matrix indexing i.e 

Let's declare 2D matrix: 

integer, dimension(5,4) :: M 

Can I write instead of: M(1,2)  = 3 the following line M(7,1) = 3 ? 

The two-dimensional matrices in old F77 code (I am working on) were indexed in both ways presented above - this does not work for Intel Parallel Studio XE 2017 with 32bit project and works with 64bit project - is it a problem of compiler settings? 

Thank you for any help/suggestions

Adam 

I see that for the program below, 2018 update 1 gives a compile time error. (compilers until 2017 update 4 didn't do so. Haven't tested it with update 5 and 6.) Just checking if it indeed "as per standard".

Abhijit

----

      Program Test
   
         Implicit None
         
         Type newOBJ
            Integer :: I
         End Type newOBJ
         Type(newOBJ) :: OBJ
         
         Associate(This => OBJ, I => This%I) ! Use of "This" is not allowed? Is that correct?
               I = 1
         End Associate
         
         ! The lines below would be what is needed
         !Associate(This => OBJ)
         !   Associate(I => This%I)  ! Breaking it into two separate associates is allowed; other option would be to use OBJ%I
         !      I = 1
         !   End Associate
         !End Associate
         
      End Program Test

Hi

Please see the snippet below. Here is what I find: with 2017 update 4, it will always crash (at the internal file read). With update 5, 6, and 2018-update 1, the exe may run the first time. Try to run it again and it will fail. Try running it again and again and once in which it will succeed.

Abhijit

----

      Program Test
         
         ! Purpose: Demonstrate the IVF 2017 update 4, 5, 6, and 2018 update 1 compiler bug(?)
   
         Implicit None
         
         Integer, Parameter :: cStngLen = 16
         Integer, Parameter :: nE = 9 ! for any value of nE > 8 there will be access violation at read statement
         
         Character(:), Allocatable :: SomeArray(:)
         Character(3) :: OM
         Integer :: J
         
         Allocate(Character(cStngLen) :: SomeArray(nE))
         SomeArray = ''
         ! Loop initialization would be ok.
         !do i=1, NE
         !  SomeArray(i) = ''
         !end do
         
         OM = '012'
         Read(OM,*) J ! Will fail here
         Write(*,*) J
         
      End Program Test

Hello

We are having difficulty debugging parallel computations based on OpenMP using Intel Fortran 16,17,18 and Visual Studio 2013 +. 

We don't have these problems using Intel Fortran  14 and Visual Studio 2010.

Here are the compiler options we are using

/nologo /debug:full /MP /Od /fpscomp:ioformat /warn:declarations /real_size:64 /Qauto /module:"x64\Debug/" /object:"x64\Debug/" /Fd"x64\Debug\vc120.pdb" /traceback /check:bounds /libs:static /threads /dbglibs /c

/Qopenmp /Z7 /MP 

We don't have any problems using the Release compilation and the parallel computing works fine. 

What happens is that in debug the program never really goes into the second thread - instead all the parallel processes are working as process 1 and of course that causes the same variables to be used by all the processes and from there it crashes.

Any ideas what we are missing?

Thank you in advance

I'm moving my sw from old Visual C++ to Visual Studio 2015 in Windows Seven environment.
My sw is written in C plus Fortran (INTEL 7.0 compiler) to interface with IMSL (7.0) library.
No problem in recompiling it and running on my developing PC.
When I move to another PC with 32 bit release I get this error: 0xc000007b
Unfortunately my sw has to run on a industrial PLC that supports only 32 bit code.
I suppose I'm using IMSL in dll mode becausethe application needs imsl_dll.dll to run.
I tried to avoid the problem linking in statically mode (to be honest this way is not recommended)
but i didn't find the way to avoid a lot of unresolved symbols.
Thanls in advance

Hi,

I have below code to use LAPACK in visual fortran compiler. But it gives the 'error #6930: The size of the array dimension is too large, and overflow occured when computing the array size [A]'.

    program deneme

    implicit none
    integer I,J,N,M,NRHS, INFO, LWORK, BLOCKSIZE
    parameter (M=90001, N=6000, NRHS=1, BLOCKSIZE=16, LWORK=N+M*BLOCKSIZE)
    double precision A(M,N), B(M,NRHS), WORK(LWORK)

    open(unit=10, file='C:\Users\Murat\Desktop\u3.txt')
    read(10,*) ((A(I,J),J=1,N),I=1,M)
    close (10)



    open(unit=11, file='C:\Users\Murat\Desktop\bdeneme.txt')
    read (11,*) ((B(I,J),J=1,NRHS), I=1,M)
    close(11)



    call dgels('No transpose', M,N,NRHS,A,M,B,M,WORK,LWORK,INFO)


    open(unit=12, file='C:\Users\Murat\Desktop\result.txt')
    do I=1,N
        do J=1,NRHS
            write (12,*) B(I,J)
        end do
    end do
    close(12)



    end program deneme

I have a crash when returning a pointer to an allocated type in a function. When the pointer is deallocated before returning, the destructor of the type is called with a wrong argument. I don't know if this has been fixed in a newer compiler. I am on   

Intel(R) Visual Fortran Intel(R) 64 Compiler for applications  running on Intel(R) 64, Version 17.0.5.267 Build 20170817

See below code. I'm sorry if I have done something that is not valid fortran or made a mistake..

program main
  use crash_module
  implicit none

  type(struct), pointer :: x

  ! Using:
  ! Intel(R) Visual Fortran Intel(R) 64 Compiler for applications
  ! running on Intel(R) 64, Version 17.0.5.267 Build 20170817
  x => crash()

end program

module crash_module

implicit none
private

public :: struct, crash

type :: struct
  private
  integer :: filler1 = 123
  integer :: filler2 = 123
  integer :: filler3 = 123
  integer :: filler4 = 123
  integer, pointer :: p => null()
contains
  private
  final :: destructor
end type

contains

impure elemental subroutine destructor(this)
  type(struct), intent(inout) :: this
  ! See that filler1, 2, 3, 4 have wrong values (should be 123).
  ! Crash because p is not null
  if (associated(this%p)) deallocate(this%p)
end subroutine

function crash() result(attribute)
  type(struct), pointer :: attribute
  allocate(attribute)
  ! destructor is called with a bogus argument.
  deallocate(attribute)
end function

end module

I have following program which is being used with abaqus software. Following code works fine with 1 cpu. However when I run on 2 cpus, I receive following error: forrtl: severe (24): end-of-file during read, unit 9.

        OPEN (UNIT=9, FILE='../inputs',
     *      form="formatted",
     *      status="OLD",
     *      access="sequential", action="read")

       read (9,*) rRpipe
       read (9,*) rRelbow
       read (9,*) rH
       read (9,*) rRHO_w
       read (9,*) rRHO_s
       read (9,*) rRHO_c
       read (9,*) rRHO_m
       read (9,*) rg
       read (9,*) rIDt

      close(9)

Could someone give the reasons and the cure ?

Thanks !

Hi,

after installing PSXE2018 update 1 I get following message when I compile my application:

deftofd: remark #10422: The IA-32 target wrapper binary 'deftofd' is deprecated.  Please use the compiler startup scripts to invoke the proper Intel(R) 64 compiler binary

I'm using Inter(R) Visual Fortran Compiler 18.0.1.156 [IA32].

I read in the release notes that the 32-bit wrappers are deprecated in Intel Compiler 18.0 and that 'Compiler users need make changes to the environment to no longer invoke the 32-bit wrappers' but I didn't find any hints what changes I have to make to get rid of this message.

Why is a call of the 32-bit version of deftofd for the 32-bit Fortran Compiler deprecated?

My build rules address deftofd without any path. I thought that's right because switching to the 64-bit compiler version will switch to the corresponding deftofd version.

Do I have to add the full path to the 64-bit version of deftofd or do I have to change the order of the paths under Executable, or Libraries under Options / Intel compilers and Tools / Visual Fortran / Compilers? Doesn't this cause some trouble with the 32-Bit Version of the Fortran Compiler?