ICE when moving parameterized derived types into different modules


I have attached two files. They contain basically the same code. array_pdt2.f90 compiles, array_pdt.f90 fails with:

$ifort array_pdt.f90

fit_lookup: Line_seq_number (nil) was not found
array_pdt.f90: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report.  Note: File and line given may not be explicit cause of this error.
compilation aborted for array_pdt.f90 (code 1)

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?

S’abonner à Fortran