Intel® Fortran Compiler

Cube Root Error

    integer(4)                                  :: i                ! a counter
    real(8),    dimension(pdlen)                :: tmp1             ! temp array for calculating
    real(8),    dimension(pdlen)                :: tmp2             ! temp array for calculating 
    <bla, bla bla >
    tmp1 = ABS(tmp2)
    do i = 1, pdlen
        skew(i) = tmp1(i)**(1/3)
    end do


   In the above code skew is being returned as an array of 1.0

   The values in tmp1 are small, but SQRT(tmp1) returns the correct answers.

Internal error (an ICE?) with a parameterized derived type

module m

   implicit none

   type :: t(n,m)

      integer, len :: n
      integer, len :: m
      real :: x(n)
      real :: y((m-1)*n)     !.. real :: y(m*n - n) compiles ok

   end type


   subroutine set(this)

      !.. Argument list
      type(t(*,*)), intent(inout) :: this

      this%x = 0.0
      this%y = 0.0


   end subroutine set

end module m


Overridden binding and parameterized derived type


I get the following error when I compile overide_pdt.f90 (attached): 

ifort override_pdt.f90

override_pdt.f90(56): error #8383: The dummy arguments of an overriding and overridden binding that correspond by position must have the same characteristics, except for the type of the passed object dummy arguments.   [TESTQ]
     PROCEDURE, PASS :: testq => test_extendedq

Installing Parallel Studio XE 2015 Update 2

I am trying to install Update 2 of Intel Parallel Studio Fortran XE 2015. I am running Mac OS 10.9.5 on a 2014 Mac Pro.


When I run both the standard install and the online custom install I get the error window "Unapproved caller. SecurityAgent may only be invoked by Apple software."

Any ideas?  Thanks very much.




The following code runs the compiler in a catastrophic error

Dear Fortran,

As shown in the tittle, the following program runs the compiler in a catastrophic error.

command line : $ ifort -coarray -coarray-num-images=4 Conv_Cata.f90
ifort -version gives :    ifort (IFORT) 15.0.0 20140723

Note : it works fine with my Windows ifort !!


Implicit length character array and bind(c) subroutine

We recently updated to IFORT A few of the regression tests for our code system now fail. The basic pattern is calling a function written in C with a slice of a two-dimensional character array; the compiler is not passing a pointer to the correct word in the character array. Here is a reduced example; we declare an interface to the C routine and iterate over the rows of a character array, passing the first column to the C function:

Problems with constant expressions


consider the following code:

program p

 implicit none

 logical, parameter :: use_v1 = .true.
 integer, parameter :: v1 = 3, v2 = 8
 integer, parameter :: &
  ! this produces a warning at compile time and wrong result
   i = v1*count( (/use_v1/) ) + v2*count( (/.not.use_v1/) )
  ! this produces an ICE at compile time
  !i = v1*count( (/use_v1/) ,kind=kind(i)) + v2*count( (/.not.use_v1/) )

 write(*,*) i

end program p

Compiling with

ifort -stand f08 p.f90 -o p

PASS attribute and parameterized derived types


I get the following error when I compile pass_pdt.f90 (attached):

pass_pdt.f90(28): error #8262: For a type-bound procedure that has the PASS binding attribute, the first dummy argument must have the same declared type as the type being defined.   [VAL]
  SUBROUTINE testq(val, this)

I explicitly attach the pass attribute to the second argument, this, and not the first. The second attached file (pass.f90) has no such issues. The only difference is that the derived type is no longer parameterized. Is this a compiler bug?

Unique system identificator choice?

Greetings everyone.

My supervisor asked me if it is possible to force an application to run only on specific PC. My first guess is to generate some sort of unique ID for the PC in question and verify it at start of application. The first thing that springs to mind is to use the Windows product ID as such unique identifier, but I've failed to find a way to get the Windows PID without launching a separate application and parsing its' output, for example, "systeminfo" provides such information, but such solution seems a bit amateur.

订阅 Intel® Fortran Compiler