Howdy.  One more trip into Legacyland.  I have reduced my issue to a small test case that works with "ye olde" g77 compiler, but does not work with Intel Fortran, even if I "USE IFPORT" to invoke the portability version of FPUTC().

The following code when compiled with g77 (apologies for the ancient style and features like equivalencing) produces a file that consists of two lines:

hi
there

      PROGRAM OPENTEST

      INTEGER RESULT,IOSTAT

      INTEGER*1 INEWLINE

      CHARACTER*1 CNEWLINE

      EQUIVALENCE(INEWLINE,CNEWLINE)

      INEWLINE=10 

      OPEN(UNIT=14,STATUS='UNKNOWN',FILE='OUT.TXT',

     *ACCESS='SEQUENTIAL',FORM='FORMATTED',RECL=512,

     *BLANK='NULL',IOSTAT=IOSTAT)

      RESULT=FPUTC(14,'h')

      RESULT=FPUTC(14,'i')

      RESULT=FPUTC(14,CNEWLINE)

      RESULT=FPUTC(14,'t')

      RESULT=FPUTC(14,'h')

      RESULT=FPUTC(14,'e')

      RESULT=FPUTC(14,'r')

      RESULT=FPUTC(14,'e')

      RESULT=FPUTC(14,CNEWLINE)

      END

Yup, it should not be that hard, but I am trying to demonstrate how the legacy code works with a trivial test case.  Note the use of FPUTC, which I am told is a g77 intrinsic function and accepts a logical unit number as the first argument.  Also notice that for the newline character, I am storing 10 in a 1-byte integer, and equivalencing it with a character.  I plan to modernize this 40-year-old application, but I first need to get the program working on Intel Fortran to have a starting point for modernization.  (These are the steps that our sponsor finds most acceptable.)

Aside, not my issue:  The program as coded above would crash on Intel Fortran when FPUTC is invoked, presumably because it is invoking the C version, which expects a pointer to a file descriptor as the first argument.  But that is easily solved by using IFPORT:

      PROGRAM OPENTEST
      USE IFPORT

      INTEGER RESULT,IOSTAT

      INTEGER*1 INEWLINE

      CHARACTER*1 CNEWLINE

      EQUIVALENCE(INEWLINE,CNEWLINE)

      INEWLINE=10 

      OPEN(UNIT=14,STATUS='UNKNOWN',FILE='OUT.TXT',

     *ACCESS='SEQUENTIAL',FORM='FORMATTED',RECL=512,

     *BLANK='NULL',IOSTAT=IOSTAT)

      RESULT=FPUTC(14,'h')

      RESULT=FPUTC(14,'i')

      RESULT=FPUTC(14,CNEWLINE)

      RESULT=FPUTC(14,'t')

      RESULT=FPUTC(14,'h')

      RESULT=FPUTC(14,'e')

      RESULT=FPUTC(14,'r')

      RESULT=FPUTC(14,'e')

      RESULT=FPUTC(14,CNEWLINE)

      END

This program results in an empty file.  I also tested with a single record, without outputing CNEWLINE, and actually saw the characters in the output file.  So this code basically works, but writing ASCII 10 obliterates each line.

My compile line is:  ifort -c -debug -save -assume nounderscore

(The application requires -save because it assumes that local variables retain their values between calls; that's just the way it is.)

Basically, in a program like this, how should I start a new line?

JayB

Steve, Colleagues,

What is the relationship between the Linker parameter "Stack Reserve Size" as set in Project Properties dropdown, and the value set with kmp_set_stacksize_s()?

It is my understanding that kmp_set_stacksize_s() allocates stack space for each thread. Is this in addition to that allocated for the "program" -- that is the master thread (number zero)? Or "within it"?  I have a very large section of code within a parallel do, and for most projects I can run 4 threads with 32,000,000 used in kmp_set_stacksize_s(). The loop involves reduction of three large arrays. In these cases the linker parameter "Stack Reserve Size" can be set to 400,000,000

I have a larger project that requires 64,000,000 in kmp_set_stacksize_s(), and runs IFF  I run only one thread; that is, use call OMP_SET_NUM_THREADS(1).  [I'm running a series of experiments to see what these parameter settings should be, in general]   If I run with 2 or more threads, I get a stack overflow error at the place in the code where the threads are being established. Altering linker parameter "Stack Reserve Size" doesn't affect this failure.

It is my assumption that the space required for private and reduced variables in the threaded region scales roughly linearly with thread count. No? The shared variables would NOT require more space with more threads -- aside, perhaps, from some minor overhead.

David

Is there a plan in the works to release a clang/llvm version of the Inspector XE tool? I notice that there is a tech preview release of PIN (2.14) for OS X Mavericks.

Hi guys,

I've got following situation:

- there is a code where I open and close a file with form='UNFORMATTED', access='SEQUENTIAL' 
- the file is open several times with position='APPEND'

The settings of the project include:
- [COMPATIBILITY] use power station I/O format = YES
- [DATA] use bytes as RECL = YES

PROBLEM
When trying to READ the data the results based on data are not correct. I've noticed that there is comma mark placed on file CLOSE.

When data is written only once to the file the results are correct. 
When SEQUENTIAL is replaced with STREAM the results are also correct. 
However I cannot use in the project I am dealing with both right now. Is there any reason why I would like to replace SEQUENTIAL with STREAM?

And the msot important question, why I get wrong results in my case? Any ideas? :)

This is a sort listing of what I am doing in the code:

      do i=1,n
         aout(i)=real(i)
         bout(i)=real(i*i)
      enddo
      iout = 20
      iin  = 21
      open(UNIT=iout,FILE='uformtest.fem',FORM='UNFORMATTED',
     1     STATUS='NEW',ACCESS='SEQUENTIAL',IOSTAT=ISTAT)
      write(iout,IOSTAT=ISTAT) (aout(i),i=1,n)
      close(iout,IOSTAT=ISTAT)
      open(UNIT=iout,FILE='uformtest.fem',FORM='UNFORMATTED',
     1     STATUS='OLD',ACCESS='SEQUENTIAL',POSITION='APPEND',
     1     IOSTAT=ISTAT)
      write(iout,IOSTAT=ISTAT) (bout(i),i=1,n)
      close(iout,IOSTAT=ISTAT)
      open(UNIT=iin,FILE='uformtest.fem',FORM='UNFORMATTED',
     1     STATUS='OLD',ACCESS='SEQUENTIAL',IOSTAT=ISTAT)
      read(iin,IOSTAT=ISTAT) (ain(i),i=1,n)
      read(iin,IOSTAT=ISTAT) (bin(i),i=1,n)
      close(iin,IOSTAT=ISTAT)

When trying to check values of ain and bin I'v found that values of ain are printed correctly values bin are all zeros.

Thans in advance for any suggestions.

Lukasz

Visual Studio seems to have started going crazy parsing my source files.  Everytime I press any key, I see the message at the bottom of the dialog that says "Parse file <filename>".  The constant delay from doing this is an big annoyance.  How do I turn this off?  In Options -> Fortran -> Advanced, I have everything set to False, except for "Disable Database", which I set to True.  It doesn't seem to help.  I'm using VS 2010, with the 2015 version of the compiler (initial release).

Of course we can get that with GRAPHICS routines, but what about regular text from Write or Print

statements?

Is there a trick that will allow other colors besides the regular white on black stuff?

I am assuming that a regular console output window is used, 

Naturally if the BACKGROUND is white, one would want to use some other color for the letters.

I stumbled upon this a couple of weeks ago...

I have a lot of reused code (via INCLUDE) which uses the STRUCTURE and then RECORD in the routines. I am not aware that RECORD can make use of the INTENT() argument, so I prefer to use TYPE.
While modifying some code I declared it as STRUCTURE in the subroutine and used TYPE to reference the STRUCTURE. I was not really intending to that, but when it compiled and ran it got me thinking...

Is it intended and OK to make use of the STRUCTURE and reference those using TYPE? It is certainly handy to be able to not have to change the INCLUDEd files, but be able to use INTENT.

Code looks like:

      PROGRAM XX
      IMPLICIT NONE
!<Old Code>
      STRUCTURE POSITION
        REAL(KIND=8) :: X, Y, Z
      END STRUCTURE
      RECORD /POSITION/  Here, There

!<New Code>
!TYPE POSITION_TYPE
!  REAL(KIND=8) :: X
!  REAL(KIND=8) :: Y
!  REAL(KIND=8) :: Z
!END TYPE POSITION_TYPE
!      TYPE(Position_Type) :: Here
!      TYPE(Position_Type) :: There

      CALL XXX(Here, There, Distance)

      END PROGRAM XX

      SUBROUTINE XXX (Here, There, Distance)
!      <Old Code>
      STRUCTURE POSITION
        REAL(KIND=8) :: X, Y, Z
      END STRUCTURE      RECORD /POSITION/  Here, There

      TYPE(POSITION), INTENT(IN   ) :: Here
      TYPE(POSITION), INTENT(IN   ) :: There
      TYPE(POSITION), INTENT(  OUT) :: Distance
      Distance = (&      (Here%X - There%X)**2 +&      (Here%Y - There%Y)**2 +&      (Here%Z - There%Z)**2    )**0.5

      END SUBROUTINE XXX

Stumbled upon an odd situation last week.

It is likely that the complier setting on the RedHat5 were using "-save" and the RedHat6 I was porting to was not.

The code looks something like this:

      PROGRAM  SunShine
      IMPLICIT NONE
!... Declarations are in here
      CALL XX(Date_n_Time, Sun_Position, SunShine)
!... File writing code is in here
      END PROGRAM SunShine

      SUBROUTINE XX(Time, Sun, SunShine)
      IMPLICIT NONE
      TYPE Position
        REAL(KIND=8) :: Lat
        REAL(KIND=8) :: Lon
        REAL(KIND=8) :: Alt
      END TYPE Position
      TYPE(Position), DIMENSION(360*181)                :: Place_as_a_Vector
!... Additional Declarations are in here...
      LOGICAL(KIND=4) DIMENSION(360,181), INTENT(  OUT) :: SunShine
      TYPE(POSITION)                    , INTENT(IN   ) :: Sun
      REAL(KIND=8)                      , INTENT(IN   ) :: Date_n_Time
      LOGICAL(KIND=4)                                   :: Init_Me = .TRUE.

      IF(Init_Me) THEN
        K = 0
        DO I = 1, 360
          DO J = -90, 90
            K = K + 1
            Place_as_a_Vector(K)%Lat = FLOAT(J)
            Place_as_a_Vector(K)%Lon = FLOAT(I)
            Place_as_a_Vector(K)%Alt = 0.0
           ENDDO
         ENDDO
        Init_Me = .FALSE.
      ENDIF
!... Some more code here...
      RETURN
      END SUBROUTINE XX

Without either ",SAVE" on "Card 15's"  "Place_as_a_Vector" declaration line, or "Place_as_a_Vector = 0" then the variable is not saved.
Are there some strategies for catching these?

"-check uninit" is one, but I am not sure if any other -warn gives insight that can help in identifying where I should be paying attention, especially when I cam coming into a subroutine or function after the first time.

There are /QSave etc, but I probably need to make sure that the code is more bullet proof, and there are quite a few lines of code.

在新发布的Intel Fortran Composer XE 2015中英特尔编译器加入了许多针对至强融核™ 协处理器编程的新特性，其中之一就是在Fortran编译器中加入了offload非连续数组片段的支持。

在使用Intel Fortran Composer XE 2015之前版本的编译器时，使用offload指令在CPU和协处理器之间传递数组片段时必须使用内存连续存放的片段。考虑下面的例子:

subroutine foo(a,b,c,n)

real::a(n,n),b(2*n,2*n),c(2*n,2*n)

integer::i,j

!dir$ offload begin target(mic) in(b(1:n,1:2*n:2),c(1:n,2:2*n:2)) out(a)

do i=1,n

   do j =1,n

      a(j,i) = b(j,2*i-1)*c(j,2*i)

   end do

end do

!dir$ end offload

end subroutine

这段代码将数组“b”的所有奇数行的前半部分和数组“c”的所有偶数行的前半部分对应位置上的元素相乘，然后将结果存放到数组“a”中。该代码在使用Intel Fortran Composer XE 2015之前版本的编译器进行编译时将会得到下面的语法错误信息：

error #8617: An array section used in IN/OUT/INOUT clause of an OFFLOAD directive must be contiguous.

由于Intel Fortran Composer XE 2015支持offload非连续数组片段，我们可以在offload指令中直接将两个不连续的数组片段传递到协处理器上进行进行计算。这段代码可以顺利的进行编译和执行。

更多关于如何通过英特尔编译器开发至强融核协处理器程序的信息请参见英特尔编译器用户参考手册的相关内容。

Hi all,

I think there is a bug , when using an allocatable type in a private list, like the small example below. For this program , I get "allocatable array is already allocated" , without openmp it works well. And No problem with gfortran either. 

Thanks.

Pat

program toto
implicit none
type qq
double precision,dimension(:),allocatable :: f
end type
call t()
contains
subroutine t()
type(qq),allocatable :: ff
double precision,dimension(:),allocatable :: f
integer :: i,j
i=0
!$omp parallel sections private(f,ff)
!$omp section
print *,i
!$omp section
allocate(f(10))
f=2
print *,'f',f
deallocate(f)
!$omp section
allocate(ff)
allocate(ff%f(5))
ff%f=5
print *,'g',ff%f
deallocate(ff)
!$omp end parallel sections
end subroutine
end program toto

Hi all ,

I got a weird behavior with the following code, looks like the variables are not correctly shared. No problem with gfortran, I'm using 15.1.

module pp
type qq
double precision,dimension(:),allocatable :: f
end type
contains
subroutine t()
type(qq),allocatable :: ff
double precision,dimension(:),allocatable :: f
integer :: i,j
i=100
!$omp task
print *,i
!$omp end task
!$omp task
allocate(f(10))
f=2
print *,'f',f
deallocate(f)
!$omp end task
!$omp task
call lili()
!$omp end task
contains
subroutine lili
print *,i
end subroutine
end subroutine
end module pp

program toto
use pp
implicit none
call t()
end program

...or has it permanently taken a dislike to my browser? I tried submitting an issue but there was no visible way to get past step 1 of 3.

Search function returned no entries for

x64

64-bit

DLL

...

Tried on IE and Chrome, so not due to ancient version of IE we have to use.

I suspect the search index has been lost????

Thanks

Hi all,

I am looking at the vectorization report of this instruction a(ipos+1:m+1)=a(ipos:m) where a is a character(20) array.  The optimization report look like that :

LOOP BEGIN at
   remark #15382: vectorization support: call to function for_cpystr cannot be vectorized
   remark #15344: loop was not vectorized: vector dependence prevents vectorization
   remark #15346: vector dependence: assumed FLOW dependence between uids line 84 and uids line 84
   remark #15346: vector dependence: assumed ANTI dependence between uids line 84 and uids line 84
LOOP END

LOOP BEGIN at
   remark #15382: vectorization support: call to function memmove cannot be vectorized
   remark #15344: loop was not vectorized: vector dependence prevents vectorization
   remark #15346: vector dependence: assumed FLOW dependence between uids line 84 and uids line 84
   remark #15346: vector dependence: assumed ANTI dependence between uids line 84 and uids line 84
LOOP END

Report from: Code generation optimizations [cg]
remark #34014: optimization advice for memmove: increase the destination's alignment to 16 (and use __assume_aligned) to speed up library implementation
remark #34014: optimization advice for memmove: increase the source's alignment to 16 (and use __assume_aligned) to speed up library implementation
remark #34026: call to memmove implemented as a call to optimized library version

I understand the flow and anti dependence, thus the use of memmove. And in the advice the memory alignement needs to be 16byte.  Does that mean that the instruction will be vectorized if the array section is aligned on 16byte ? And Should i increase the character to character(32) and then I won't have to make sure the size of the array section is a multiple of 16 ?

If so , I am using -aling array16byte compiler option, do I still need to use __assume_aligned or the compiler will deduce it automatically ?

Thanks.

Pat.

Hi,

I have a base type called TObject, a type that extends TObject called TCollection and a type that extends TCollection called TBlock.

In TObject i have a public field "character(len=:),allocatable :: Name"
In TBlock I set a procedure (function) also called Name (procedure::Name)

This causes an ICE when compiling. Changing the field or the procedure name to other thing solves the problem.

I attached a working project to exemplify the ICE. I am using Intel Fortran 15.0.1.148.

If that's the case, shouldn't the compiler warn that this is not possible?

Cheers,

Eduardo Jauch

I have a type with two bound procedures (GetAsScalar & GetAsList) under a generic procedure (GetValue):

type, extends(TObject)  ::  TKeyword
    character(len=:), allocatable               ::  fValue

contains
    procedure, private                          ::  GetAsScalar
    procedure, private                          ::  GetAsList

    generic                                     ::  GetValue    =>  &
                                                    GetAsScalar,    &
                                                    GetAsList
end type TKeyword

The routines signatures are these:

subroutine GetAsScalar (this, value, status)
    !Arguments-------------------------------------------------------------
    class(TKeyword)                                 ::  this
    class(*), target                                ::  value
    logical, optional                               ::  status

    !...
end subroutine GetAsScalar

subroutine GetAsList (this, value, status)
    !Arguments-------------------------------------------------------------
    class(TKeyword)                                 ::  this
    class(*), pointer                               ::  value(:)
    logical, optional                               ::  status

    !...
end subroutine GetAsList

Internally, the TKeyword object stores a string.

If I try to use it in the following way (bellow), I get a compilation error: "There is no matching specific subroutine for this type bound generic subroutine call"

class(TKeyword), pointer :: key
class(*), pointer :: p(:)
allocate (integer::p(3))

!Code to read instantiate the TKeyword object

call key%GetValue(p, status)

select type (p)
type is (integer)
    write (*,*) p
end select

If I remove the GetAsScalar from the generic association and make it public, the following code works as expected:

class(TKeyword), pointer :: key
class(*), pointer :: p(:)
allocate (integer::p(3))

!Code to read instantiate the TKeyword object

call key%GetAsList(p, status)

select type (p)
type is (integer)
    write (*,*) p
end select

When passing a scalar (integer, real, character, etc), the GetAsScalar routine is called without problems.

I would like to know why this is happening. What am I missing in this "generic thing" that makes the compiler unable to recognize my subroutine under the generic? There is a way to make this work? Would be something related with the routine signature?

I'm using Intel Fortran 15.0.1.148

Hello all,

I have a general installation question about Intel^® Inspector XE and and the other Intel software development products.  Once you've installed an update, is it okay to uninstall previous updates if they aren't uninstalled automatically?  For example, if I have "Intel Inspector XE 2015 Update 2" installed, will uninstalling "Intel Inspector XE 2015 Update 1" affect the functionality of the product?  And does the same go for the other Intel software development products such as Intel Composer XE? 

Thank you all in advance for your help,

Brandon