I have successfully got a project going with VS2010 C/C++ and Intel Fortran thanks to help here but I want to compile essentially the same code on a second machine. This machine did not have VS C/C++ so we purchased Intel C/C++ and Intel Fortran. Both installed okay, but I am not having any luck getting the C++ into the fortran project at all. I can add the wrap.c to a fortran project, but it doesnt appear to get compiled. I cant create a C/C++ static library either when I have created a fortran solution.

Looking on web, it appears you have to have Visual Studio standalone before you can use Intel C/C++ inside it! I thought going all intel might reduce problems not increase them. Oh well. So... I could could presumably compile my c file from command line, but then what do I need to do in the VS fortran side to get this to link in? Do I have to create a static library from the command line as I do when Visual C/C++?

Hi

I am using Visual studio 2008 and FORTRAN 9.1 to compile and link and FORTRAN code to ASPEN plus, now while before I created FORTRAN codes in other version of FORTRAN. There is no problem in compiling the existing FORTRAN codes and link them to ASPEN plus by this combination of versions, however I cannot find how I can create new FORTRAN codes in the current version of Visual studio!'

Does any one has any idea about this?

I have a old scientific Fortran program that made liberal use of allocating one very large array in the main routine and then chopping up the array (memory) for smaller use by passing multiple chunks to Subroutines by using an offset.  The array in the main program was of type real or double precision and in the receiving routine it could be defined as integer, real or double precision.  Also, in the receiving program the dimension of the array could be a single dimension or multi-dimension.

How do I tell the complier to not check the arguments for this type of inconsistency?  I would like to be able to do this for the entire program in one place.

Here's and example:

       program mymain

       dimension a(20)

       n1=1

       n2=n1+7

       n3=n2+6

       n4=n3+3

       call dowork( a(n1), a(n2), a(n3), a(n4) )

       stop

       end

       subroutine dowork( ifirst, asecond, ithird, afourth)

       dimension ifirst(7), ithird(3)

       double precision afourth

       dimension asecond(2,3), afourth(2)

c      Do work

       return

end

Hi

I have a code in FORTRAN and it runs sequentially without problem (I compile it with /O3 and x64 platform). Then I add OpenMp syntaxes to make the code more optimized. This time it gives me "Stack overflow" message (even if I run it ). I increased stack reserve size to about 1GB but it does not work.

Here is part of the code that change to make it parallel: 

    call OMP_SET_NUM_THREADS(6);
    !$OMP PARALLEL DO DEFAULT(PRIVATE) SHARED(g_num,g_coord,nn,nels,anatyp)   &   
    !$OMP SHARED(coord_elm_center,loc_ele_cor,wix4,der4,fun4,Shear_Skeleton)  &
    !$OMP SHARED(EleMode,v,vu,Biot_Coef,c,dtim,permx,Kr,cT,gam,omg2,gcor8)    &
    !$OMP SHARED(wix8,eqn,counter1,counter2,counter3,counter4,counter5,Th_Exp)&
    !$OMP SHARED(lan,lan1,der8,fun8,gcor20,wix20,fun20,der20,gcor40,wix40)    &
    !$OMP SHARED(fun40,der40,gcor61,wix61,fun61,der61) SCHEDULE(DYNAMIC)      &
    !$OMP REDUCTION (+:Lhs,LhsSig,LhsU,A15,A25,A35,A45,A55_Heat)
    Main: do iel=1, nels
 $  DO SOEM CALCULATION

    enddo Main;
    !$OMP END PARALLEL DO 

I appreciate any help.

  Hello

     I tried a simple 'hello' coarray and at runtime I got this:

                                                                          unknown option: -localonly

    what those this means?

             thanks in advance

There are two questions I would like an explanation for in the simple test below:

1. Why doesn't the code issue an error at run time - since the allocation of the coarray specifies different bounds on image 1 and images >1?

2. Why does the code run to completion at all? I thought there was an implicit barrier (SYNC ALL) for the allocation of any coarray, and that this barrier had to correspond to the same line of code. Or is it sufficient to have coarray allocations with the same bounds (even if said allocation occurs in different parts of the program)?

(1) looks like a bug - the Cray compiler works as intended in this case; (2) I am not so sure (actually it's better not to have the requirement of a barrier on the same ALLOCATE statement (same line of code).

Thanks,
Olivier

PROGRAM COARRAY_TEST

IMPLICIT NONE

INTEGER,ALLOCATABLE :: TEST(:)[:]

! Master thread

IF (THIS_IMAGE()==1) THEN

ALLOCATE(TEST(2)[*])

TEST = THIS_IMAGE()

! Slave threads

ELSE

ALLOCATE(TEST(4)[*])

TEST = THIS_IMAGE()

ENDIF

! Write TEST

WRITE(*,'(A,I4,A,10I4)') 'Image #',THIS_IMAGE(),' Array value:',TEST

END PROGRAM COARRAY_TEST

Hi everyone,

I'm trying to compile a Software call Delft 3D with VS2010 and Intel Composer 2013. I download the last version of Intel Visual Fortran Compiler, but the source code is create of the version 13.0.1.119 and I use 14.0.2.176.

How can I get a older version of the compiler?

Thanks for your help

Guillaume

Hi,

I compile with success my code with Intel Visual Fortran and i used it without problem.

But when i send my exe to a friend his antivirus identify it as a virus.

How is it possible? Is there anything i can do to fix the problem?

Thanks in advance

Fabrizio

Hello all, Aside the annoying issue with the .pdb file that get locked most of the time when the debug session is stopped manually (that can be workaround with sysinternals handle.exe tool), I have a problem with the debugger that hangs randomly when an intrinsic function (like allocate, minloc) is stepped over. The debugger indicates "Running" and the execution of the intrinsic takes forever. It does not depend on the size of the arrays given in parameter to the intrinsic. The only solution I have found is to break the debugger ("Break All"), move the cursor to the next line and then "Continue to cursor". Is it a know issue ? Is there a workaround ? Visual Studio 2012 Update 4 Intel(R) Composer XE 2013 SP1 Update 2 (package 176)

I was playing around with a way to record log messages in an internal "file" (character variable) when I came upon a strange compiler notice. The following module does not compile, producing the error

error #7146: This object must not be used as an allocate-object in an allocate-stmt or deallocate-stmt in a PURE procedure or an internal procedure contained in a PURE procedure.   [TEMP]
      allocate(temp(2*size(this%buffer)), mold = this%buffer)

Simply removing the associate construct gets rid of the error. Allocation and internal file I/O should both be fine in PURE procedures, right?

module logmod
  implicit none
  private

  type, public :: logger
    private

    character(128), allocatable :: buffer(:)
    integer :: idx = 1
  contains
    procedure, public, pass(this) :: info
  end type logger

contains

  pure subroutine info(this, msg)
    class(logger), intent(inout) :: this
    character(*), intent(in)  :: msg

    ! Temporary buffer
    character(:), allocatable :: temp(:)

    ! This unused association causes error #7146
    associate(i => this%idx)

      ! Check buffer status
      if (.not. allocated(this%buffer)) then
        ! Allocate and fill buffer of initial size 100
        allocate(this%buffer(100))
        this%buffer = ''

      elseif (this%idx == size(this%buffer)) then
        ! Increase buffer size
        allocate(temp(2*size(this%buffer)), mold = this%buffer)
        temp(1:size(this%buffer)) = this%buffer
        call move_alloc(temp, this%buffer)
      endif

      write(this%buffer(this%idx), '(a)') msg
      this%idx = this%idx + 1
    end associate
  end subroutine
end module

When calling a subroutine that "exits early" due to failed input parameter value validation I get:

Unhandled exception at 0x003d0541 in vmpsI.exe: 0xC0000005: Access violation reading location 0xfffffffc.

The subroutine and calling program are attached.

  o  When calling the subroutine with a value of N less than 6 the runtime error is ALWAYS encountered.

   o  When calling with N=6 it OCCASIONALLY will return to the calling program as expected.

   o  ONCE I got a fatal heap corruption error.

  o  The SUBROUTINE follows.  Note that "SomeArray" must be declared to generate the RTE.

! ThisIsBS.
!
! Minimal routine to generate the WTF runtime error.


        SUBROUTINE ThisIsBS(S, N, D, H1Vals, H2Vals, info)

        IMPLICIT NONE


        ! Generic two-dimensional array.
        TYPE Array2d
            SEQUENCE
            DOUBLE PRECISION, ALLOCATABLE, DIMENSION(:,:) :: val
        END TYPE Array2d


        INTEGER, INTENT(IN) :: S
        INTEGER, INTENT(IN) :: N
        INTEGER, INTENT(IN) :: D
        DOUBLE PRECISION, DIMENSION(S,S), INTENT(IN) :: H1Vals
        DOUBLE PRECISION, DIMENSION(S,S), INTENT(IN) :: H2Vals
        INTEGER, INTENT(OUT) :: info


        DOUBLE PRECISION :: foo
        INTEGER :: bar
        INTEGER :: baz


        ! This is an array that WOULD HAVE been used later in the subroutine
        ! had the validations passed.  So please don't submit this code to
        ! TheDailyWTF.com.  I just ripped out EVERYTHING from the subroutine
        ! but this, WHICH IS BLOWING THIS DAMNED THING UP!!!!!!!!!!!!!!!!!!!
        TYPE(Array2d), DIMENSION(0:N+1,1:N) :: SomeArray


        ! Initialize the return value.
        info = 0

        ! Ensure the value of N is valid.
        IF (N < 4) THEN
            info = -1
            GOTO 999
        ENDIF

        ! Ensure the value of D is greater than zero.
        IF (D < 1) THEN
            info = -2
            GOTO 999
        ENDIF

        ! Ensure the value of D is a power of 2.
        IF (D /= 2**INT(LOG(D*1.) / LOG(2.))) THEN
            info = -3
            GOTO 999
        ENDIF

        ! Ensure the values of N and D are valid and compatible.  Specifically
        ! D may not be "too big" for N.
        IF (D > 2**INT((N-4)/2)) THEN
            info = -4
            GOTO 999
        ENDIF


999     RETURN

        END

  o  The calling program follows.

! Run Variational Matrix Product States (VMPS).
!
! This program will run the VMPS routine.


        PROGRAM RunVMPS

        IMPLICIT NONE

        ! The number of spin states per particle.
        INTEGER, PARAMETER :: S=2

        ! The number of particles in the chain.
        INTEGER :: N

        ! The maximum bond dimension.
        INTEGER :: D


        ! The values of the matrix elements of the DxD one- and two-body operators that
        ! make up the nearest neighbor Hamiltonian (for spin 1/2):
        !
        !  | <up|O|up> <up|O|dn> |
        !  | <dn|O|up> <dn|O|dn> |
        !
        ! Here we define two arrays:
        !   o  H1Vals for the matrix elements of the one-body operator.
        !   o  H2Vals for the matrix elements of the two-body operator.
        DOUBLE PRECISION, DIMENSION(S,S) :: H1Vals
        DOUBLE PRECISION, DIMENSION(S,S) :: H2Vals

        ! Return value from the VMPS routine.
        INTEGER :: info


        ! Initialize the matrix elements of the operators.
        ! Since the values in Fortran arrays are stored in column major order, these
        ! values correspond to <up|O|up>, <dn|)|up>, <up|O|dn>, and <dn|O|dn>,
        ! respectively. To convert these values into their 2x2 matrix we use:
        !
        !     TRANSPOSE(RESHAPE(..., (/ 2, 2 /)))
        !
        H1Vals = TRANSPOSE(RESHAPE((/ -1.0d0, 0.0d0, 0.0d0, 1.0d0 /), (/ 2, 2 /)))
        H2Vals = TRANSPOSE(RESHAPE((/ 0.0d0, 1.0d0, 1.0d0, 0.0d0 /), (/ 2, 2 /)))

        WRITE(*,*) "I am alive."

        N=4
        D=3
        CALL ThisIsBS(S,N,D,H1Vals,H2Vals,info)

        WRITE(*,*) "I am dead."


        STOP

        END

My environment:

  o  Windows 7 Ultimate 64 bit SP1

  o  Visual Studio 2010 Premium

  o  Intel(R) Visual Fortran     Package ID: w_fcompxe_2013_sp1.1.139

  o  Intel(R) Visual Fortran Composer XE 2013 SP1 Update 1 Integration for Microsoft Visual Studio* 2010, 14.0.0074.2010, Copyright (C) 2002-2013 Intel Corporation

Inconsistent Compiler Error checking using Intel 10.1 FORTRAN on WIn 7

Currently  using VS 2008 and Intel FORTRAN 10.1 on Win 7 enterprise.  Running 32 bit version of these on a 64 bit machine.   Using DEBUG settings only, compiler license is housed on a server.

I have  been noticing that compliation and linking of some development code will show successful creation of an executible with no errors on several consecutive "rebuild solution" attempts. (sometimes as many as 5-8) However on a later attempt, with no changes to the code, the complier suddenly finds an error in variable type, syntax, etc that it did not find on the previous attempts.  This seems rather unpredictable except that when it finally finds the error, it continues to find it.  Errors range from undeclared variables to dummy and acutal argument types not matching.

It is a bit of a troubling mystery that it doesn't find those errors every time.    Being a developer, I am concerned that I could create a binary that won't function correctly because the compiler missed an error during a "successful" attempt.

Look forward to replies.  Thanks.

Pat

I have problems with a Fortran program reading contents from a named pipe in Linux. This can be experienced, for example, using awk:

ifort -O test_fifo.f90 -o test_fifo

rm -f file.fifo

mkfifo file.fifo

awk 'BEGIN { line=0; \
             while (1) { line = line + 1; \
                         printf "%d01", line; \
                         for (i=2;i<=17;i++) printf " %d%02d", line, i; \
                         for (i=1;i<= 7;i++) printf " %.2f", line+i/100.0; \
                         print ""; } }'> file.fifo &

./test_fifo

where named pipe file.fifo is created and awk is used to write lines of 17 integer and 7 float columns so that they can be detected. Program test_fifo.f90 simply reads the lines and checks the first and the last columns:

program test_fifo

implicit none

integer, parameter :: int_small = selected_int_kind(9)
Integer, parameter :: real_low  = selected_real_kind(p=6, r=30)

integer(kind=int_small)     :: scols(17)
real(kind=real_low)         :: fcols(7)
character(len=*), parameter :: filename = 'file.fifo'
integer                     :: unit = 11, line, io

print*,'Opening file ', filename
open(unit, file=filename, action='read', form='formatted', iostat=io)
if (io /= 0) then
  print*,'Unable to open file ', filename
  stop
end if

line = 0
do while (.TRUE.)
  line = line + 1

  ! Read 17 integer columns and 7 float columns:
  scols = 0
  fcols = 0.0
  read(unit,*,iostat=io) scols, fcols

  ! Check the first integer and the last float column:
  if ((scols(1) /= line*100 + 1) .OR. (fcols(7) /= line + 0.07)) then
    print*,'Mismatch on line ', line, ':'
    print*, scols, fcols
  end if

  ! Check for io errors (and eof):
  if (io /= 0) then
    print*,'Read returned ', io, ' on line ', line
    exit
  end if
end do

end program test_fifo

For majority of the input lines this works well but once in a while there is a corruption in the read:

 Mismatch on line           67 :
        6701        6702        6703        6704        6705           6
         706        6707        6708        6709        6710        6711
        6712        6713        6714        6715        6716   6717.000    
   67.01000       67.02000       67.03000       67.04000       67.05000    
   67.06000    
 Mismatch on line           99 :
        9901        9902        9903        9904        9905        9906
        9907        9908        9909        9910        9911         991
           2        9913        9914        9915        9916   9917.000    
   99.01000       99.02000       99.03000       99.04000       99.05000    
   99.06000    
 Mismatch on line          208 :
       20801           2         802       20803       20804       20805
       20806       20807       20808       20809       20810       20811
       20812       20813       20814       20815       20816   20817.00    
   208.0100       208.0200       208.0300       208.0400       208.0500    
   208.0600    
...

where contents of a column is clearly split into two separate numbers. This happens in three environments:

• CentOS 5.9,   ifort 12.1.1.256 Build 20111011
• Ubuntu 12.04, ifort 13.1.2.183 Build 20130514
• CentOS 6.5,   ifort 14.0.1.106 Build 20131008

With GNU Fortran (gfortran) the example is working correctly.

The problem seems to be related to the output buffering mode of awk. If the output is flushed after each line:

                         print ""; fflush(); } }'> file.fifo &

or if the buffering mode is changed with stdbuf to line-buffered:

stdbuf -oL awk 'BEGIN { line=0; \

there is no corruption. Unfortunately the program writing to the named pipe is user-given and stdbuf is not available for some of the target environments, so a Fortran side of a solution is desirable.

Is ifort working properly here/for you? Is there a compile time option or open/read parameter that can change the behavior?

Thanks,

  Matti

This is a bit hard to describe, and unbelievable, too!

All of a sudden, one of our files can not be compiled by ifort anymore, and as I look into the cause of the failure, it looks like -fpp really mess up the compilation - this particular file has a lot of #ifndef, #ifdef blocks.

here is the findings:

1) by using -save-temps, I was able to get the .i file, and with that file, I can compile it successfully with either -fpp or without -fpp option.

2) If the source file is located on a local disk, say, /local/user/builder/source/v740/s/gtsuite/src/mainb.F, the ifort can compile it with -fpp.

3) If the source file is referred on a NFS mount (either direct nfs mount, or automount - auto.home or auto.direct), example: /home/builder/source/v740/s/gtsuite/src/mainb.F, it complains about syntax error - totally non-sense output

-bash-3.2$ /opt/intel/composer_xe_2011_sp1.13.367/bin/ia32/ifort  -extend_source 132 -r8 -DGTDOUBLE -D_ALL_UNIX_ -D_HAVE_FOAM -assume underscore -assume protect_parens -fPIC -align dcommon -fpp -save-temps -module . -I/home/builder/source/v740/s -I. -c -O2 /mnt/source/v740/s/gtsuite/src/mainb.F -o GTsuite/obj/mainb.o  /mnt/source/v740/s/gtsuite/src/mainb.F(1745): error #5149: Illegal character in statement label field  [t]
.        if(idrvopt.eq.0)then
^
/mnt/source/v740/s/gtsuite/src/mainb.F(1745): error #5149: Illegal character in statement label field  [/]
.        if(idrvopt.eq.0)then
-^
/mnt/source/v740/s/gtsuite/src/mainb.F(1745): error #5149: Illegal character in statement label field  [i]
.        if(idrvopt.eq.0)then
----^
/mnt/source/v740/s/gtsuite/src/mainb.F(1745): error #5276: Unbalanced parentheses
.        if(idrvopt.eq.0)then
------------------------^
/mnt/source/v740/s/gtsuite/src/mainb.F(1745): error #5082: Syntax error, found IDENTIFIER 'EXTRA_OUTVOPT' when expecting one of: <END-OF-STATEMENT> ;
.        if(idrvopt.eq.0)then
------^
/mnt/source/v740/s/gtsuite/src/mainb.F(1758): error #6305: An ELSE statement occurred without a corresponding IF THEN statement.
        else
--------^
/mnt/source/v740/s/gtsuite/src/mainb.F(1760): error #6317: An ENDIF occurred without a corresponding IF THEN or ELSE statement.
        endif
--------^
/mnt/source/v740/s/gtsuite/src/mainb.F(1772): error #6309: An ELSEIF statement occurred without a corresponding IF THEN statement.
      elseif(iflag.eq.2)then
------^
/mnt/source/v740/s/gtsuite/src/mainb.F(1795): error #6309: An ELSEIF statement occurred without a corresponding IF THEN statement.
      elseif(iflag.eq.3)then
------^
/mnt/source/v740/s/gtsuite/src/mainb.F(1810): error #6317: An ENDIF occurred without a corresponding IF THEN or ELSE statement.
      endif
------^
/mnt/source/v740/s/gtsuite/src/mainb.F(2682): remark #8291: Recommended relationship between field width 'W' and the number of fractional digits 'D' in this edit descriptor is 'W>=D+7'.
          write(c80,"('Case#',i4,', Step ',i8,', dt = ',1p,g9.3,', t =',g12.5,A)") icase, istep, dt, time, word(:16)
------------------------------------------------------------^
compilation aborted for /mnt/source/v740/s/gtsuite/src/mainb.F (code 1)

Somehow the combination of -fpp with nfs mounted path is consistently giving this failure.

4) I have confirmed the failure with either Solaris 10 as NFS server or RHEL6 as NFS server - so I think the nfs server can not be the cause of this.

5) This problem happened just recently after we added a new nisMap object to our Active Directory, which has nothing to do with the source file location at all. I remember at the same time, we update our Active Directory functional level to use 2008 (from 2000). I could not think of any relationship between the build failure and the above AD changes we made. But the 2 events are correlated in time somehow. 

Has anyone seen stuff like this? Should I open a case with Intel support?

I have modules that reference each other.  Is there any way to do this; e.g., pre-compiled modules?  My desired code sequence would have the following pattern:

• module M1 source. This uses module M1, references subroutine S2, and contains array A1.  All objects are public.
• module M2 source. This uses module M1, contains subroutine S2, and references array A1.  All objects are public.
• main program P source.  This uses modules M1 and M2 and references subroutine S2 and array A1.

I suspect this will not compile (if I do it in one step) because of the circular references; so, I did not try it.  How about the following approach?

• Compile M1 source as a separate step.
• Compile M2 source as a separate step.
• Compile P source with a command that references the pre-compiled forms of M1 and M2.

[[I apologize for earlier not submitting this as a separate thread.]]

Tried updating Xcode to 5.1, but it seems to have dropped my FORTRAN 14.0 compiler after multiple attempts to re-install the compiler after the upgrade.  Downgraded Xcode to 5.0.2 and everything works fine again.  Not sure what Apple changed, but it looks like Xcode 5.1 doesn't support the Intel FORTRAN compiler once again.

With update 2 of the Composer XE Fortran (and C++) compilers on a RedHat 6.5 32-bit system, the compilation process leaves a fifo file of the form

prw-------.   1 fitchk kklsim      0 Mar 13 17:19 intelremotemonfifo.500

in the directory where the source file exists.  Normally, I wouldn't care, but when you try to do a grep "something" *, the grep hangs when it gets to the fifo.  It's annoying to have to delete this file manually.  How can I make the compiler either a) not create the fifo in the first place, or b) cleanup after itself once the compilation is complete.

I gather that this is part of the remote monitoring feature, which I opted not to use when I installed update2.  I also verified that monitoring is disabled using the "ism" tool.

I am using W8.1 togeter wih VS2013 and IVFComposer 2013. The program I am working with is a MDI application. A feature is to open and edit files, which used to work fine up to now. But suddenly VS2013 stop working every time I try to open a file as shown below. I wonder if it is due to a windos upgrade. I hope someone can give me a tip.. (Open file secton and the intitialize open file name structure  is shown below)

Open file:

case (IDM_OpenFile)

! get open file dialog box

Ofn%Flags = null

szfilter = 'TVC input files(*.inp)'&

// char(0) // '*.inp' // char(0)

Ofn%LPSTRINITIALDIR = loc(trim(InputDir)//Char(0))

iret = InitializeOpen()

bret = GETOPENFILENAME(Ofn)

bret=.true.

! check to see if the OK button has been pressed

if(bret == 0) then ! check for error

call COMDLGER(ierror)

! ierror is the returned error value

MainWndProc = 0

return

else

lpszCaption = &

szFileName(1+Ofn%NFILEOFFSET:Ofn%NFILEEXTENSION-1)

ext = szFileName(Ofn%NFILEEXTENSION+1: &

Ofn%NFILEEXTENSION+3)

end if

integer*4function InitializeOpen()

! intitialize open file name structure 

useMultiPadGlobals

use DEFAULTS_TV

use comctl32

implicit none

! szfilter = 'MultiPad data files(*.txt)'&

! // char(0) // '*.txt' // char(0)

Ofn%lStructSize = sizeof(Ofn)

Ofn%hwndowner = ghwndMain

Ofn%hinstance = gHinstance

Ofn%lpstrfilter = LOC(szfilter)

Ofn%LPSTRCUSTOMFILTER = NULL

Ofn%NMAXCUSTFILTER = 0

Ofn%NFILTERINDEX = 1

Ofn%LPSTRFILE = LOC(szFileName)

Ofn%NMAXFILE = LEN(szFileName)

! Ofn%LPSTRFILETITLE = loc(szTitleName//".txt"C)

Ofn%NMAXFILETITLE = 50 ! 25

! Ofn%LPSTRINITIALDIR = NULL ! loc(inputdir) !

Ofn%LPSTRTITLE = null

! Ofn%FLAGS = NULL

Ofn%NFILEOFFSET = NULL

Ofn%NFILEEXTENSION =NULL

! Ofn%LPSTRDEFEXT = loc("*.txt"C)

Ofn%LCUSTDATA = NULL

Ofn%LPFNHOOK = NULL

Ofn%LPTEMPLATENAME = NULL

initializeOpen = 1

return

end

Hi

We updated Intel Visual Fortran Composer XE 2011 to XE 2013 SP1 and Visual Studio 2008 to 2010 Premium.

It seems that the VALUE attribute is not working anymore and it's not recognized as a special word in Visual Studio.

Here's small sample:

Fuction specification:

integer(4) function csta_sect_num(selected, mode)
	use, intrinsic :: ISO_C_BINDING
	use CSE_STA_USER

	IMPLICIT NONE
	
	LOGICAL(C_BOOL), VALUE, intent(in)	:: selected
	integer(C_INT), optional, intent(in)	:: mode
...

Interface:

interface csta_sect_num
	function csta_sect_num (selected, mode) result (num)
		use, intrinsic :: ISO_C_BINDING
		implicit none
		logical(C_BOOL), VALUE, intent(in)    :: selected
		integer(C_INT), optional, intent(in)  :: mode
		integer(C_INT)                        :: num
	end function csta_sect_num
end interface csta_sect_num

C++ declaration:

extern "C" int csta_sect_num (bool selected, int * mode = 0);

C++ function call:

bool sel = false;
int num = csta_sect_num(sel);

The selected argument gets passed by reference and will crash the program.

If I add

BIND(C,NAME='csta_sect_num')

to the function definition and to its interface, it will work, or if I add the

!DIR$ ATTRIBUTES VALUE :: selected

compiler directive to the parameter, it will also work.

Shouldn't the VALUE attribute work also without neither of these additions?

br

Janne

Dear Steve et al. at Intel,

The code listed below compiles with no errors or warnings using Intel Fortran compiler version 13.1.0.149 even if Fortran 2003/2008 standards checking is turned on.  This seems to be a violation of C1277 of Fortran 2003 standard that says:

 
8 12.7 Elemental procedures
 
9 12.7.1 Elemental procedure declaration and interface
 
10 An elemental procedure is an elemental intrinsic procedure or a procedure that is defined by an
11 elemental subprogram.
 
12 An elemental subprogram has the prefix-spec ELEMENTAL. An elemental subprogram is a pure sub
13 program. The PURE prefix-spec need not appear; it is implied by the ELEMENTAL prefix-spec. The
14 following additional constraints apply to elemental subprograms.
 
15 C1277 All dummy arguments of an elemental procedure shall be scalar dummy data objects and shall
16 not have the POINTER or ALLOCATABLE attribute.
 
17 C1278 The result variable of an elemental function shall be scalar and shall not have the POINTER or ALLOCATABLE attribute.
 

Can you please review and follow-up as you think is appropriate?  Perhaps it has been fixed in compiler 14, the latest update?

   MODULE foo
 
      TYPE t
      END TYPE t
 
   CONTAINS
 
      PURE ELEMENTAL SUBROUTINE foo1(x)
 
         TYPE(t), ALLOCATABLE, INTENT(INOUT) :: x
 
      END SUBROUTINE foo1
 
      PURE ELEMENTAL SUBROUTINE foo2(x)
 
         TYPE(t), ALLOCATABLE, INTENT(OUT) :: x
 
      END SUBROUTINE foo2
 
      PURE ELEMENTAL SUBROUTINE foo3(x)
 
         TYPE(t), ALLOCATABLE, INTENT(IN) :: x
 
      END SUBROUTINE foo3
 
   END MODULE foo