Dear all,

We have a project with multiple Fortran sources (~100) where few of them are also preprocessed (.F). We tried to switch on parallel compilation of source files (/MP), but on some machines the compilation fails (repeatable) with the error message (which appears after output of the preprocessed source files in the log file)

ifort: command line error: multiple sources; asm output option must specify dir

Relevant compile command:

/nologo /MP /O2 /I"some_include_folders" /D"some_defines" ... /libs:static /threads /c /Qvec-report0 /names:lowercase /assume:underscore /iface:nomixed_str_len_arg /fp:source /extend_source:132 /fp:source /Qip /O2 /MD /fpe:3 ...

Intel Fortran version:

Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 13.0.1.119 Build 20121008

integrated to VS2010

How can we detect the source of the error? Why it is triggered only on some machines? 

Thanks,

Peter

Hello!

I got the next error and I don't know what to do:

Error: A license for FCompW is not available now (-96,491).

A connection to the license server could not be made. You should

make sure that your license daemon process is running: both an

lmgrd.exe process and an INTEL.exe process should be running

if your license limits you to a specified number of licenses in use

at a time. Also, check to see if the wrong port@host or the wrong

license file is being used, or if the port or hostname in the license

file has changed.

License file(s) used were (in this order):

1. Trusted Storage

2. 28518@BUC-PLAT-APP02

3. C:\Program Files (x86)\Common Files\Intel\Licenses\COM_W__FOR_Fxxx_xxxxxxxx.lic

4. C:\Program Files\Common Files\Intel\Licenses

5. c:\PROGRA~2\intel\COMPOS~1\bin\ia32\*.lic

Please visit http://software.intel.com/sites/support/ if you require technical assistance.

ifort: error #10052: could not checkout FLEXlm license

Thank you!

Error: A license for FCompW is not available now (-96,491).

A connection to the license server could not be made. You should

make sure that your license daemon process is running: both an

lmgrd.exe process and an INTEL.exe process should be running

if your license limits you to a specified number of licenses in use

at a time. Also, check to see if the wrong port@host or the wrong

license file is being used, or if the port or hostname in the license

file has changed.

License file(s) used were (in this order):

1. Trusted Storage

2. 28518@BUC-PLAT-APP02

3. C:\Program Files (x86)\Common Files\Intel\Licenses\COM_W__FOR_xxx_xxxxxxx.lic

4. C:\Program Files\Common Files\Intel\Licenses

5. c:\PROGRA~2\intel\COMPOS~1\bin\ia32\*.lic

Please visit http://software.intel.com/sites/support/ if you require technical assistance.

ifort: error #10052: could not checkout FLEXlm license

I don't think that this is right!  It's not polymorphic ....

MODULE Assign

    IMPLICIT NONE

    INTEGER :: factor

    TYPE, PUBLIC :: Mytype

        INTEGER :: comp = 123

    CONTAINS

        PROCEDURE, PRIVATE :: Copy

        GENERIC :: ASSIGNMENT (=) => Copy

    END TYPE Mytype

CONTAINS

    PURE SUBROUTINE Copy (a, b)

        CLASS(Mytype), INTENT(OUT) :: a

        CLASS(Mytype), INTENT(IN) :: b

        a%comp = b%comp*factor

    END SUBROUTINE Copy

END MODULE Assign

PROGRAM Main

    USE Assign

    IMPLICIT NONE

    TYPE(Mytype) :: coarray[*]

    factor = THIS_IMAGE()

    SYNC ALL

    IF (THIS_IMAGE() == 1) THEN

        coarray = coarray[2]       ! (a)

        coarray[3] = coarray       ! (b)

        coarray[4] = coarray[5]    ! (c)

    END IF

END PROGRAM Main

ifort version 14.0.2

gerbil.f90(25): error #8392: If the actual argument is a polymorphic coindexed object, the dummy argument must not be polymorphic.   [COARRAY]

        coarray = coarray[2]       ! (a)

------------------^

gerbil.f90(26): error #8392: If the actual argument is a polymorphic coindexed object, the dummy argument must not be polymorphic.   [COARRAY]

        coarray[3] = coarray       ! (b)

--------^

gerbil.f90(27): error #8392: If the actual argument is a polymorphic coindexed object, the dummy argument must not be polymorphic.   [COARRAY]

        coarray[4] = coarray[5]    ! (c)

--------^

gerbil.f90(27): error #8392: If the actual argument is a polymorphic coindexed object, the dummy argument must not be polymorphic.   [COARRAY]

        coarray[4] = coarray[5]    ! (c)

---------------------^

compilation aborted for gerbil.f90 (code 1)

Hi,

when I installed Intel Visual Fortran Composer XE 2013 SP1, I got program icon " Using VS2010". But when I launch the program, the VS2010 pro starts, but there is no Fortran template in the Installed Templates (when creating New Project).

How do I get the Fortran working with the VS2010?

Operating sytem is Win7 64-bit.

Greetings:

            I have upgraded to Eclipse Luna and am running the parallel tools plugin (which includes Photran).  This has worked out extremely well using their refactoring tools ... auto converting to "implicit none" is very sweet.

            Unfortunately I can not find anywhere on the web, any clues to getting Intel FORTRAN  introduced as a tool chain. (Even though this MUST exist because of the Linux support). I believe without the compiler being in the the tool chain, CDT/PTP cannot index files appropriately. Since there is no index, there is no editor help for code completion etc. .....I am happy rolling my Makefiles, but feeding an IDE's indexer is a requirement. 

             I have worked with this compiler through the COMPAQ-HP-Intel days.... we Windows/FORTRAN guys need some IDE love. (and please don't suggest Visual Studio again)

Regards

Carl

I have a larger program that passes a data type into a deallocation subroutine that is a pointer, but the compilation fails saying the data type does not match.

Here is a simplified version of the code:

      MODULE DATATYPE
      TYPE EX1
          INTEGER,DIMENSION(:),ALLOCATABLE:: A
      END TYPE
      !
      TYPE, EXTENDS(EX1)::EX
          INTEGER:: B
      END TYPE
      !
      CONTAINS
      !
      SUBROUTINE SUB(STRUCT)
      CLASS(EX1),POINTER:: STRUCT
      !
      SELECT TYPE(STRUCT)
      TYPE IS (EX)
          DEALLOCATE(STRUCT)
      END SELECT
      !
      END SUBROUTINE
      END MODULE
      
      PROGRAM MAIN
      USE DATATYPE
      TYPE(EX),POINTER:: STRUCT
      !
      ALLOCATE(STRUCT)
      CALL SUB(STRUCT)
 
      END PROGRAM

The compiler error I get is:

Error    1     error #6633: The type of the actual argument differs from the type of the dummy argument.   [STRUCT]   

The code works fine if I drop the POINTER attribute where I say CLASS(EX1),POINTER:: STRUCT

Is this a compiler error or is there no way to have the POINTER attribute with CLASS.

Thanks in advance as always!

I am compiling a large fortran computer model that contains lots of data types and pointers. The visual studio project under Properties then "Fortran>Preprocessor>Preprocessor Definitions" has the keyword "ALIGN". I have spoken with several other developers and no one knows why it was added. What that keyword does is add to the command line "/DALIGN"

I have tried searching the documentation and forums, but have been unable to determine what exactly this is doing. The code compiles just fine with our without the keyword.

Any opinions or descriptions what ALIGN is doing would be greatly appreciated.

In a MDI application I open several windows. After opening the windows are overlapping each other and then I will to arrange them with the program lines:

                case (IDM_VTILE)

                   iret = SendMessage(ghwndClient, &

                                  WM_MDITILE, MDITILE_VERTICAL, 0)                  

                   MDIWndProc = 0

                   return

This works fine, but let’s say I have three windows. Window number 3 will be at the left,

window 2 in the middle and window number 1 to the right.

I want the windows to be arranged in reversed order compared to what Windows does.

Is there any (simple) way to solve this?

The hello work coarray code

  1 program Hello_World
  2 implicit none
  3 integer :: i  ! Local variable
  4 character(len=20) :: name[*] ! scalar coarray, one "name" for each image.
  5 ! Note: "name" is the local variable while "name[<index>]" accesses the
  6 ! variable in a specific image; "name[this_image()]" is the same as "name".
  7
  8 ! Interact with the user on Image 1; execution for all others pass by.
  9 if (this_image() == 1) then
 10 write(*,'(a)',advance='no') 'Enter your name: '
 11 read(*,'(a)') name
 12
 13 ! Distribute information to other images
 14 do i = 2, num_images()
 15 name[i] = name
 16 end do
 17 end if
 18
 19 sync all ! Barrier to make sure the data have arrived.
 20
 21 ! I/O from all images, executing in any order, but each record written is intact.
 22 write(*,'(3a,i0)') 'Hello ',trim(name),' from image ', this_image()
 23 end program Hello_world

ifort -coarray hello.f90 -o hello
./hello
  File "/opt/intel/composerxe/mpirt/bin/intel64/mpd", line 1545
    except Exception, errmsg:
                    ^
SyntaxError: invalid syntax
  File "/opt/intel/composerxe/mpirt/bin/intel64/mpdallexit", line 99
    print __doc__
                ^
SyntaxError: invalid syntax

ifort -v
ifort version 14.0.2

python --version
Python 3.4.1

How to solve the mpd error?

HI, Could someone tell me the differences between compiler option -no-vec and -no-simd?

Do I have to use both options to disable auto-vectorization from the Intel Compiler for some specific files?

If I just use one option, such as  -no-vec, in terms of Intel Fortran compiler manual, the default option is still to enable SIMD vectorization. I am confused about these 2 options and why are there 2 compiler options for auto-vectorization?

Thanks and I look forward to your response.

Hi,

I'm wondering is the following code is valid.

I'm defining a type bound procedure which has 2 argument:

1. the passed-object dummy argument with the attribute 'intent(inout)'
2. a integer variable with the attribute 'intent(in)'

If the actual argument associated to the dummy argument n°2 is a component of the passed-object dummy argument and if this component is modified in the TBP, then there is an inconsistency since the argument n°2 is declared as 'intent(in)' but its value is actually changing.

Below, an example which run without any warnings or errors

! ifort main.f90; ./a.out
Module MyModule
  implicit none
  private
  public        ::      MyType
  Type          ::      MyType
    integer     ::      Var
  contains
    procedure   ,public ::      Do_Something_Inconsistent
  End Type
  contains
Subroutine Do_Something_Inconsistent( This, Var )
  class(MyType)         ,intent(inout)  ::      This
  integer               ,intent(in)     ::      Var
  This%Var      =       Var + 1
End Subroutine
End Module
Program Main
  use MyModule  ,only:  MyType
  implicit none
  type(MyType)  ::      Obj
  Obj%Var       =       1
  write(*,"('BEFORE: Obj%Var = ',g0)") Obj%Var
  call Obj%Do_Something_Inconsistent( Obj%Var )         ! Is this valid
  write(*,"('AFTER:  Obj%Var = ',g0)") Obj%Var
End Program

sd

Dear Dr. Fortran:

At least this consultation will not cost me the $30 copay for the usual Dr's appointments.

So I finally got back to Australia after 2 years in Texas.  The skiing, according to my cousins, was the best in the last two decades, so I took my daughter and went skiing. It was like finding an IDE that let you seamlessly link Fortran and Lisp. Wonderful.

So I am at Thredbo, I leave my daughter on the simple runs and move to Gun Barrel. Looks like the 40 mile Paris Gun from WWI. Black Diamond with a Most Difficult tag on the top of the run. Stand on top of a 5 storey building and look straight down, not quite as steep as Gun Barrel, but it is at least a soft landing - wind chill -22 degrees C, blowing ice particles and not a soul on the run (I wonder why). I make it to the bottom - ok I had to stop once to catch my breath. Stack it in the dip at the bottom - I am lying in the snow, skis buried to the boots in the hill, thought - bindings must be to tight did not release boots, breathing like there is no air, heart is pounding and then think I am having a heart attack - my first thought was of Dr. Fortran - thanks Dr. Fortran I took your advice, took a few deep breaths and then rested for a minute. Heart felt better and I could actually feel the O2 return to my brain.  20 minutes later I am again standing on my skis - takes a while to release from the position I was in and I still had the other half to face -

Finally on the bottom half - there is a guy on a snowboard half way down, he stands up and then falls forward onto this face, flips onto his back - stuck in an infinite do loop - very funny - but not for him I ski up behind him and point to the kiddy run - yes we Fortran programs are hard on those Basic Folks.

Get to the bottom and my daughter looks at me and says - you were only gone for 10 minutes, I say no at least 40 and she says no - ten.  Must have been in a OS2 Warp.

Thanks Doctor - you are the best

An old Fortran Skier.

I'm in a time crunch and unsure in my current frame of mind as to where all I should look to understand this, so thought I'd ask here: can procedures returning ALLOCATABLE types be exported from a dynamic-link library (DLL)?

Consider the simple example below:

FUNCTION foo() RESULT(Message)

   !.. Function result
   CHARACTER(LEN=:), ALLOCATABLE :: Message

   Message = "Hello World!"

   RETURN

END FUNCTION foo

Can such a function be exported from a DLL and called from another program, say a Fortran console application?  I get a run-time library exception when I do so:

forrtl: severe (157): Program Exception - access violation
Image              PC        Routine            Line        Source
ntdll.dll          76F4E41B  Unknown               Unknown  Unknown
ntdll.dll          76F4E023  Unknown               Unknown  Unknown
kernel32.dll       757614AD  Unknown               Unknown  Unknown
...
...

Are function exports a no-no that is widely known, but about which I was unaware?

This may overlap with previous issues, but is simpler.

PROGRAM Main

    TYPE :: Mytype

        INTEGER, ALLOCATABLE :: ptr(:)

    END TYPE Mytype

    TYPE(Mytype) :: coarray[*]

    ALLOCATE(coarray%ptr(3))    

    IF (THIS_IMAGE() == 2) coarray%ptr = 123

    SYNC ALL

    IF (THIS_IMAGE() == 1) THEN

        coarray = coarray[2]

        PRINT *, coarray%ptr

    END IF

END PROGRAM Main

 -1083162920       32767 -1083162920

Hi everybody, can someone help me please. This time I''m facing another problem with my code, it just starts running and then stops with massage:

Binary was not built with debug information

I don't understand what does it mean

Where should we look for the latest information about the upcoming Intel Visual Fortran (IVF) 15.0?  E.g., what legitimate information is there about new features that will be included and likely release dates?

Please let us know anything that you're allowed to tell us.  TIA.

I'm compiling a GUI application, and have set the SubSystem to /SUBSYSTEM:WINDOWS.  This has the normal behavior of not opening a command shell when the application is launched by double clicking it.  However, what I would like is this: when the application is launched from a command shell (cmd -> cd to the exe directory -> type exe name), I would like write(*,*) statements in the code to show up in the shell.  Currently, of course, they do not appear.  Basically, I want to build one executable that can be used as a normal application, but also has a command-line mode when launched from a DOS shell.  Is such a thing even possible?

Other than a plain, old bug, can anyone think of situations where DEALLOCATE statement will not deallocate the provided object, but yet it won’t return an error code and an error message?

We’ve a major problem with one of the use cases for an important code library where DEALLOCATE statement runs into such a problem.  The pseudo code is as follows:

    ...
    INTEGER :: Istat
    CHARACTER(LEN=80) :: ErrAlloc
    ...
    IF (ALLOCATED(Foo)) THEN
       DEALLOCATE(Foo, STAT=Istat, ERRMSG=ErrAlloc)  ! <= returns Istat of 0
       IF (Istat /= 0) THEN
          ... ! error handling
          RETURN
       END IF
    END IF
    ALLOCATE(Foo, STAT=Istat, ERRMSG=ErrAlloc) ! <-- failure, Istat=151; Foo already allocated.
    IF (Istat /= 0) THEN
       ... ! error handling
       RETURN
    END IF
    ...

where Foo is an instance of an extensible derived type containing allocatable components as well as type-bound procedures.

The issue is the ALLOCATE statement fails with an error code of 151 and returns an error message, “an allocatable array is already allocated.” because the DEALLOCATE in the code block just prior to this hasn't done its its job but hasn't returned an error.   Note the IF (ALLOCATED(..)) check does indeed return true.  

Isn't DEALLOCATE statement always supposed to return a non-zero error code if it is unable to deallocate the object for any reason?

The application structure is as follows: a Fortran main program calls DLL A which calls DLL B.  The main program has a “TYPE(Foo_t), ALLOCATABLE :: Foo” kind of declaration.  Foo is an argument specified with “TYPE (Foo_t), INTENT(INOUT) :: ” in some of the procedures in DLLs A and B which, under certain circumstances, will need to deallocate and reallocate Foo.  The code is built with /standard-semantics compiler option.

Any thoughts on what to check before I start thinking of this as a bug?

Dear colleagues,



Several months ago I had successfully developed a user subroutine in FORTRAN for a particular commercial finite element software (ABAQUS). I decided several days ago to extend this subroutine and the resulting subroutine is quite complex, big, and involves several big matrices/arrays (over 10 thousand lines) that are exchanged among subroutines with COMMON BLOCKS.



The thing is that the subroutine does not compile and I get the following error:



Abaqus Error: The executable standard.exe aborted with system error code 1073741819. 



There is no other information in any other file. It is important to note that this kind of error could be due to many reasons and is different than the error that appears as a consequence of poor programming. However, I thought that maybe I had define wrongly some of the variables of the code: I thoroughly checked all the code and tried to locate the error. My surprise came when I saw that, reducing the number of lines of the big matrices/arrays mentioned before, the subroutine works. Those matrices/arrays are all of them initialized (the suppressed lines only contain 0s) and I have checked that its dimensions agree through all the code. Searching on the internet I see that some people with similar problems say that it could be due to memory problems. Could it be? What could I do to solve it?

I know that usually, in the 95% of the cases, when subroutines don't work this is due to poor programming. However, in this case there are several circumstances that make me think that it could be to other reasons. Among them, if I add to the subroutine the following statement WRITE, the above mentioned error appears again, independently of the variable (A or other).



WRITE(7,*) 'A equals:', A 



(Note that in this statement the number 7 indicates that the message is written to a particular file of the FE software).

Searching on the internet I have also found this nice post by Steve Lionel:



https://software.intel.com/en-us/articles/memory-limits-applications-win...

I wonder if it is my case and if I can do anything to solve the problem, since I use quite a lot of static code but unfortunately I am not able to reduce it due to the limitations of not having access to the main code.



Thank you very much for your help