Quantcast
Channel: Intel® Software - Intel® Fortran Compiler for Linux* and macOS*
Viewing all 2746 articles
Browse latest View live

command line remark #10148: option '-i-dynamic' not supported

$
0
0

Hello:

How do I fix this error? The file (used in conjuction with Abaqus) is attached!

ifort: command line remark #10148: option '-i-dynamic' not supported

Please help! Thanks!

Mousumi

AttachmentSize
Downloadapplication/octet-streamumat_sdvini4.f2.25 KB

New WG5 web site and Fortran 2020 feature survey!

$
0
0

For many years, the "web home" of ISO/IEC JTC1/SC22/WG5 (the international Fortran standards committee, or WG5 for short) has been graciously hosted by NAG. I am pleased to announce that WG5 now has its own web site: https://wg5-fortran.org/ The site is served over https and is "mobile friendly".

The WG5 web site is where you'll find news about what's happening with the Fortran standard, and links to all WG5 documents. Information on current and past standards is also available there.

On the home page you will see a link to a survey, requesting opinions on and suggestions for features that you would like to see in the next Fortran standard, tentatively titled Fortran 2020. If you want to help shape the future of Fortran, please take a few minutes and fill out the survey. While the survey will remain open through January 2018, we will start analyzing responses at the October J3 meeting. Also, the list of features the survey asks you to rank may be amended based on suggestions received.

I welcome all comments on the web site, and especially if you discover any problems. Not yet done are the email list indexes and news older than 2016.

speed difference contiguous pointers vs call_by_reference

$
0
0

Hi there,

in the course of modernizing some of my code I have moved to putting many "call by refernce" routines which were previously "stand-alone" behind types. In addition arrays are now passed using type bound pointers, usually with the "contiguous" attribute. This has the big advantage of avoiding to pass array boundaries explicitly (because many of my arrays start at index value zero). However, I have noticed a speed difference to an extent that the type bound routines need up to twice as much time for processing large arrays than the direct routines.

The below program mimics the above structure. It implements the frist part of an implicit multiplication of a 4.5 Mio x 100 matrix with an 4.8 Mio x 4.8 Mio structured sparse co-variance matrix (the latter matrix can be stored in form of four vectors and is held by the type). This routine needs about 4.8 seconds when called directly, and about 6.6 seconds when called through the type. This is n ot a big difference in absolute numbers, but sums up when performed several thousand times. Given that the type transports the array into the routine via a pointer with attribute "contiguous" this difference in speed should not appear. however, may be I haven't understood the standard incorrectly. The speed was measured on a Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz with 56 processors. The compiler was ifort 17.4. The data set can be supplied on request.

Any Ideas?

Thanks a lot

Module Mod_Direct
contains
  Subroutine SubDrop(ISUBound1,ISUBound2,RMInOut,ivi,ivs&&,ivd,rvp,ISNThreads)
    !$ use omp_lib
    Implicit None
    Integer*8, Intent(In) :: ISUbound1, ISUBound2
    Real*8, Intent(InOut) :: RMInOut(0:ISUbound1,1:ISUBound2)
    Integer*8, Intent(In) :: ivs(:), ivd(:), ivi(:)
    Real*8, Intent(In) :: RVp(:)
    Integer*4, intent(in), optional :: ISNThreads
    Integer*8 :: c1, c2, ss, dd, ii
    outer:block
      RMInOut(0,:)=0.0D00
      !$ if(present(ISNThreads)) Then
      !$   if(ISNThreads>size(RMInOUt,2)) Then
      !$     call omp_set_num_threads(size(RMInOut,2))
      !$   else
      !$     call omp_set_num_threads(ISNThreads)
      !$   End if
      !$ else
      !$   c1=omp_get_max_threads()
      !$   if(c1>size(RMInout,2)) Then
      !$     call omp_set_num_threads(size(RMInout,2))
      !$   else
      !$     call omp_set_num_threads(int(c1,4))
      !$   End if
      !$ end if
      !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1)
      Do c1=1,size(RMInOut,2)
        Do c2=1,size(IVI,1)
          ss=ivs(c2)
          dd=ivd(c2)
          ii=ivi(c2)
          RMInOut(ii,c1)=RMInOut(ii,c1)+rvp(c2)*(RMInOut(ss,c1)&&+RMInOut(dd,c1))
        End Do
      End Do
      !$OMP END PARALLEL DO
    End block outer
  End Subroutine SubDrop
end Module Mod_Direct
Module Mod_Type
  Type :: Testtype
    Integer*8, Allocatable :: ivi(:), ivs(:), ivd(:)
    Integer*8 :: isn
    Integer*4 :: ISSubStat
    Real*8, Allocatable :: rvp(:)
    Real*8, Pointer, contiguous :: RMInout(:,:)
    Character(:), allocatable :: csmsg
  contains
    procedure, pass, public :: drop=>subdrop
  End type Testtype
  Interface
    Module Subroutine SubDrop(this,ISNThreads)
      Class(TestType) :: this
      Integer*4, optional :: ISNThreads
    end Subroutine
  End Interface
  Private :: SubDrop
end Module Mod_Type
SubModule(Mod_Type) Drop
contains
  Module Procedure SubDrop
  !$ use omp_lib
    Implicit None
    Integer*8 :: c1, c2, ss, dd, ii
    outer:block
      if(.not.associated(this%RMInOut)) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      end if
      if(lbound(this%RMInOut,1)/=0) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      End if
      if(ubound(this%RMInOut,1)/=this%isn) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      End if
      this%RMInOut(0,:)=0.0D0
      !$ if(present(ISNThreads)) Then
      !$   if(ISNThreads>size(this%RMInOUt,2)) Then
      !$     call omp_set_num_threads(size(this%RMInOut,2))
      !$   else
      !$     call omp_set_num_threads(ISNThreads)
      !$   End if
      !$ else
      !$   c1=omp_get_max_threads()
      !$   if(c1>size(this%RMInout,2)) Then
      !$     call omp_set_num_threads(size(this%RMInout,2))
      !$   else
      !$     call omp_set_num_threads(int(c1,4))
      !$   End if
      !$ end if
      !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1)
      Do c1=1,size(this%RMInOut,2)
        Do c2=1,size(this%ivi,1)
          ss=this%ivs(c2)
          dd=this%ivd(c2)
          ii=this%Ivi(c2)
          this%RMInOut(ii,c1)=this%RMInOut(ii,c1)+this%RVP(c2)&&*(this%RMInOut(ss,c1)+this%RMInOut(dd,c1))
        End Do
      End Do
      !$OMP END PARALLEL DO
    End block outer
  end Procedure
End SubModule Drop
Program Test
  use Mod_Type
  use Mod_Direct
  Implicit none
  Type(TestType) :: TST
  integer :: dim=4876565, dim3=100, c1
  real*8, target, allocatable :: rmtmp(:,:)
  real*8 :: t0, t1
  !$ call omp_set_nested(.TRUE.)
  Allocate(TST%ivi(dim),TST%ivs(dim),TST%ivd(dim),TST&&%rvp(dim))
  open(55,file="input.txt",action="read")
  Do c1=1,dim
    read(55,*) TST%ivi(c1),tst%ivs(c1),tst%ivd(c1),tst%rvp(c1)
  end Do
  tst%isn=maxval(tst%ivi)
  Allocate(rmtmp(0:tst%isn,dim3),source=0.0D0)
  !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  TST%RMInOut=>rmtmp
  call TST%drop()
  !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  !!call SubDrop(ISUBound1=Int(tst%isn,8),ISUBound2=Int(dim3,8),RMInout&
  !!  &=rmtmp,ivi=tst%ivi,ivs=tst%ivs,ivd=tst%ivd,rvp=tst%rvp)
End Program Test

 

Compiler not warning on poor syntax in DO loop construct

$
0
0

I've been chasing my tail for an hour trying to understand why some variables were not initialised and finally twigged that I had a missing comma in a do loop.

I had;

DO J=NCHAN, 1 -1

   DO STUFF

END DO

I had missed the comma between the end of iteration control and the step. I have IMPLICIT NONE and  I'm compiling with  -c -m64 -g -check all -debug full -traceback -warn all -heap-arrays

Shouldn't this get flagged at compile time? I'm using XE 2017 Update 4.

Cheers

Kim

parallel programming using OPENMP

$
0
0

 

Hi ifort develiper and users,

I have written a fortran code(where four loops are present) in openMP. Here i share the openMP code, where the second loop is parallelized.

first: do i=1,NMAX,1
xmsd_1(i) = 0.0
!$omp parallel default(none) &
!$omp shared (NTMAX,nmol,i,com_xu,P_1,xmsd_1) &
!$omp private(k,m,dx,xmsd,pr_1)
!$omp do reduction(+:xmsd_1)
second: do j=1,NTMAX,1
third : do k =1,nmol,1

pr_1 = 1
fourth : do m=jframe,jframe+iframe,1
        pr_1 = pr_1 * P_1(m,k)
end do fourth

if(pr_1 .eq. 1) then
dx = com_xu(k,j+i) - com_xu(k,j)
xmsd = dx*dx
xmsd_1(i) = xmsd_1(i) + xmsd * pr_1
end if

end do third
end do second
!$omp end do 

!$omp end parallel

print*, i,xmsd(i)

end do first

My openMP code(where second loop was parallelized) results do not match the serial code results.  could you please suggest a solution to this problem?

 

Determining DIRECT_IO_FACTOR on Linux

$
0
0

Hello,

 

 

I have compiled Quantum Espresso (QE) in a Linux cluster using intel2016.4.258 and openmpi-2.1.1. I get a runtime error for IOSTAT=121. The DIRECT_IO_FACTOR ( block length byte) in the QE code is set to 8. 

My understanding is that DIRECT_IO_FACTOR is system dependent. Is there a way to find out what DIRECT_IO_FACTOR value is on any Linux system?

Thank you,

Vahid

Visual Studio Code?

Initializing allocatable arrays to NaN

$
0
0

Hello,

 

A search indicates that this question was asked (in the Fortran for Windows Forum) before, but that was three years ago, and I can't find any update.

I'm using Intel Fortran version16.1 and I'd like to initialize allocatable arrays to NaN to aid in debugging.  I am familiar with the -ftrapuv and -init=snan,array options but it is my understanding they do not work for allocatable arrays.  The answer in the three year old question I found was "it is something we are working on for the future".  It is now the "future", and since that topic is closed, I've opened a new question to ask again.  Has that capability been added?  Or is it still part of future plans?

Chris Harrop


__intel_avx_rep_memcpy page fault

$
0
0

Dear All,

I'm using Systemstamp probes (vm.pagefault) to avoid page faults in my code by forcing to read/write in all memory. The probe says that __intel_avx_rep_memcpy has page fault:

fault address: 0x424000, symbol: __intel_avx_rep_memcpy+0x80/0x17c0, access: r, type: minor, delay: 36

according to asm it is:

(gdb) info symbol __intel_avx_rep_memcpy+0x80
__intel_avx_rep_memcpy + 128 in section .text

0x0000000000423fb9 <+121>:	shr    $0x2,%r9
0x0000000000423fbd <+125>:	sub    %r9,%r11
0x0000000000423fc0 <+128>:	cmp    %r11,%rcx
0x0000000000423fc3 <+131>:	jae    0x424060 <__intel_avx_rep_memcpy+288>
0x0000000000423fc9 <+137>:	nopl   0x0(%rax)

So could you help me to understand what memory should be forced there?

Regards,

Roman

Compilation options for error checking

$
0
0

Recently I found a compilation difference between the compiler for Linux and the one for windows. The Windows one can report some errors, like miss matching of dummy arguments and actual ones, which the Linux one can't.  I'd like to know if there is any option which can force the compiler to do that. Thanks!

ICE: Error for submodule with functions using format "Module Procedure" ->"End Procedure"

$
0
0

Hi, the following code produces an ICE.

Module MyModule
  implicit none
  private
  Type ,public  ::  MyType
    integer     ::  N = 2
  contains
    procedure   ::  DoSomething
  End Type
  Interface
    Pure Module Function DoSomething( This, Inp ) result(Out)
      class(MyType)               ,intent(in) :: This
      integer ,dimension(This%N)  ,intent(in) :: Inp
      integer ,dimension(This%N)              :: Out
    End Function
  End Interface
End Module

Submodule(MyModule) MySubModule
  implicit none
  contains
! !   WORKS
!     Pure Module Function DoSomething( This, Inp ) result(Out)
!       class(MyType)               ,intent(in) :: This
!       integer ,dimension(This%N)  ,intent(in) :: Inp
!       integer ,dimension(This%N)              :: Out
!       Out = Inp * This%N
!     End Function
!   DO NOT WORKS
    Module Procedure DoSomething
      Out = Inp * This%N
    End Procedure
End Submodule

Program Main
  use MyModule ,only: MyType
  type(MyType)  :: Obj
  write(*,* ) Obj%DoSomething([1,2])
End Program

using ifort version 17.0.4.

The error comes from the "Module Procedure" ... "End Procedure" form for declaring submodule procedures.

If The procedure interface is repeated, then the error goes away.

I thought initially that this error was related to issue DPD200413234.

See https://software.intel.com/en-us/forums/intel-fortran-compiler-for-linux-and-mac-os-x/topic/707181.

 

MM_PREFETCH re REAL data

$
0
0

In the IVF documentation, Intrinsic subroutine, MM_PREFETCH

In descriptions

hint = 0 ... Use this for integer data
hint = 1 ... Use this for REAL data

The compiler directive PREFETCH does not have this description. Examples seem to indicate fetching REALs to L1 may be effective.

Does this mean that MM_PREFETCH-ing of REALs to L1 is not (generally) effective? .OR. implies that the VPU does not fetch from L1?

Please explain.

Jim Dempsey

Catastrophic error with Intel Compiler 17

Intel compiler integration with Photran under MacOS

speed difference contiguous pointers vs call_by_reference

$
0
0

Hi there,

in the course of modernizing some of my code I have moved to putting many "call by refernce" routines which were previously "stand-alone" behind types. In addition arrays are now passed using type bound pointers, usually with the "contiguous" attribute. This has the big advantage of avoiding to pass array boundaries explicitly (because many of my arrays start at index value zero). However, I have noticed a speed difference to an extent that the type bound routines need up to twice as much time for processing large arrays than the direct routines.

The below program mimics the above structure. It implements the frist part of an implicit multiplication of a 4.5 Mio x 100 matrix with an 4.8 Mio x 4.8 Mio structured sparse co-variance matrix (the latter matrix can be stored in form of four vectors and is held by the type). This routine needs about 4.8 seconds when called directly, and about 6.6 seconds when called through the type. This is n ot a big difference in absolute numbers, but sums up when performed several thousand times. Given that the type transports the array into the routine via a pointer with attribute "contiguous" this difference in speed should not appear. however, may be I haven't understood the standard incorrectly. The speed was measured on a Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz with 56 processors. The compiler was ifort 17.4. The data set can be supplied on request.

Any Ideas?

Thanks a lot

Module Mod_Direct
contains
  Subroutine SubDrop(ISUBound1,ISUBound2,RMInOut,ivi,ivs&&,ivd,rvp,ISNThreads)
    !$ use omp_lib
    Implicit None
    Integer*8, Intent(In) :: ISUbound1, ISUBound2
    Real*8, Intent(InOut) :: RMInOut(0:ISUbound1,1:ISUBound2)
    Integer*8, Intent(In) :: ivs(:), ivd(:), ivi(:)
    Real*8, Intent(In) :: RVp(:)
    Integer*4, intent(in), optional :: ISNThreads
    Integer*8 :: c1, c2, ss, dd, ii
    outer:block
      RMInOut(0,:)=0.0D00
      !$ if(present(ISNThreads)) Then
      !$   if(ISNThreads>size(RMInOUt,2)) Then
      !$     call omp_set_num_threads(size(RMInOut,2))
      !$   else
      !$     call omp_set_num_threads(ISNThreads)
      !$   End if
      !$ else
      !$   c1=omp_get_max_threads()
      !$   if(c1>size(RMInout,2)) Then
      !$     call omp_set_num_threads(size(RMInout,2))
      !$   else
      !$     call omp_set_num_threads(int(c1,4))
      !$   End if
      !$ end if
      !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1)
      Do c1=1,size(RMInOut,2)
        Do c2=1,size(IVI,1)
          ss=ivs(c2)
          dd=ivd(c2)
          ii=ivi(c2)
          RMInOut(ii,c1)=RMInOut(ii,c1)+rvp(c2)*(RMInOut(ss,c1)&&+RMInOut(dd,c1))
        End Do
      End Do
      !$OMP END PARALLEL DO
    End block outer
  End Subroutine SubDrop
end Module Mod_Direct
Module Mod_Type
  Type :: Testtype
    Integer*8, Allocatable :: ivi(:), ivs(:), ivd(:)
    Integer*8 :: isn
    Integer*4 :: ISSubStat
    Real*8, Allocatable :: rvp(:)
    Real*8, Pointer, contiguous :: RMInout(:,:)
    Character(:), allocatable :: csmsg
  contains
    procedure, pass, public :: drop=>subdrop
  End type Testtype
  Interface
    Module Subroutine SubDrop(this,ISNThreads)
      Class(TestType) :: this
      Integer*4, optional :: ISNThreads
    end Subroutine
  End Interface
  Private :: SubDrop
end Module Mod_Type
SubModule(Mod_Type) Drop
contains
  Module Procedure SubDrop
  !$ use omp_lib
    Implicit None
    Integer*8 :: c1, c2, ss, dd, ii
    outer:block
      if(.not.associated(this%RMInOut)) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      end if
      if(lbound(this%RMInOut,1)/=0) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      End if
      if(ubound(this%RMInOut,1)/=this%isn) Then
        this%CSMSG="ERROR"
        this%ISSubStat=1;exit outer
      End if
      this%RMInOut(0,:)=0.0D0
      !$ if(present(ISNThreads)) Then
      !$   if(ISNThreads>size(this%RMInOUt,2)) Then
      !$     call omp_set_num_threads(size(this%RMInOut,2))
      !$   else
      !$     call omp_set_num_threads(ISNThreads)
      !$   End if
      !$ else
      !$   c1=omp_get_max_threads()
      !$   if(c1>size(this%RMInout,2)) Then
      !$     call omp_set_num_threads(size(this%RMInout,2))
      !$   else
      !$     call omp_set_num_threads(int(c1,4))
      !$   End if
      !$ end if
      !$OMP PARALLEL DO PRIVATE(ss,dd,c2,c1)
      Do c1=1,size(this%RMInOut,2)
        Do c2=1,size(this%ivi,1)
          ss=this%ivs(c2)
          dd=this%ivd(c2)
          ii=this%Ivi(c2)
          this%RMInOut(ii,c1)=this%RMInOut(ii,c1)+this%RVP(c2)&&*(this%RMInOut(ss,c1)+this%RMInOut(dd,c1))
        End Do
      End Do
      !$OMP END PARALLEL DO
    End block outer
  end Procedure
End SubModule Drop
Program Test
  use Mod_Type
  use Mod_Direct
  Implicit none
  Type(TestType) :: TST
  integer :: dim=4876565, dim3=100, c1
  real*8, target, allocatable :: rmtmp(:,:)
  real*8 :: t0, t1
  !$ call omp_set_nested(.TRUE.)
  Allocate(TST%ivi(dim),TST%ivs(dim),TST%ivd(dim),TST&&%rvp(dim))
  open(55,file="input.txt",action="read")
  Do c1=1,dim
    read(55,*) TST%ivi(c1),tst%ivs(c1),tst%ivd(c1),tst%rvp(c1)
  end Do
  tst%isn=maxval(tst%ivi)
  Allocate(rmtmp(0:tst%isn,dim3),source=0.0D0)
  !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  TST%RMInOut=>rmtmp
  call TST%drop()
  !!@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  !!call SubDrop(ISUBound1=Int(tst%isn,8),ISUBound2=Int(dim3,8),RMInout&
  !!  &=rmtmp,ivi=tst%ivi,ivs=tst%ivs,ivd=tst%ivd,rvp=tst%rvp)
End Program Test

 


Compiler not warning on poor syntax in DO loop construct

$
0
0

I've been chasing my tail for an hour trying to understand why some variables were not initialised and finally twigged that I had a missing comma in a do loop.

I had;

DO J=NCHAN, 1 -1

   DO STUFF

END DO

I had missed the comma between the end of iteration control and the step. I have IMPLICIT NONE and  I'm compiling with  -c -m64 -g -check all -debug full -traceback -warn all -heap-arrays

Shouldn't this get flagged at compile time? I'm using XE 2017 Update 4.

Cheers

Kim

will ifort be intergrated into vs mac osx?

$
0
0

ifort will fail when xcode is updated. however, the undate is so frequent.

 

More than 7200 characters

$
0
0

Is there any way to lift the 7200 characters per line restriction in ifort?

The reason is that I'm using some macros to avoid code duplication and they can be pretty long (whole functions sometimes).

Finalisation of Abstract Type

$
0
0

 

So I have an abstract type with allocatable length strings

type, abstract:: firstType
   character(len=:), allocatable:: one, two
  contains
end type

I want to be able to include a final  subroutine:

type, abstract:: firstType
    character(len=:), allocatable:: one

  contains
    final:: destroyFirst
end type

contains

subroutine destroyFirst(typeIn)
end subroutine

Is it possible?   When I try to use type(firstType) then I get 

 error #8313: The TYPE(derived-type-spec) shall not specify an abstract type.

but when I try to use class(firstType) I get the error

error #8339: The dummy argument of a final subroutine must be a variable of the derived type being defined and cannot be optional, pointer, allocatable, or polymorphic.

Is it possible to finalise an abstract type?

polymorphic variables: assignment "poly = a" and "a = poly"

$
0
0

Hello, I'm discovering the pleasures of the OOP and I'm faced with a problem depending on the compiler (ifort vs gfortran).  Consider this first simple module:

module typedefs
   implicit none

   type base_t
      integer :: i = 0
   end type base_t

   type, extends(base_t) :: ext1_t
      integer :: j = 0
   contains
      procedure :: ext1EqCl
      generic :: assignment(=) => ext1EqCl
   end type ext1_t

   interface assignment(=)
      module procedure generic_assign
   end interface

contains

   subroutine generic_assign (lhs, rhs)
      class(base_t), intent(in )              :: rhs
      class(base_t), intent(out), allocatable :: lhs
      print*,'--> generic_assign'
      allocate (lhs, source=rhs)
   end subroutine generic_assign

   subroutine ext1EqCl (lhs, rhs)
      class(base_t), intent(in ) :: rhs
      class(ext1_t), intent(out) :: lhs
      print*,'--> ext1EqCl'
      select type(rhs)
         type is (ext1_t)
            lhs%i = rhs%i ; lhs%j = rhs%j
      end select
   end subroutine ext1EqCl

end module typedefs

program test

   use typedefs
   implicit none
   class(base_t), allocatable :: p
   type(ext1_t) :: a1

   print '(/,a)','*** do : a1 = ext1_t (1,2) ***'
   a1 = ext1_t (1,2)

   print '(/,a)','***  do : p = a1 ***'
   p = a1

   print '(/,a)','*** do : a1 = p ***'
   a1 = p ; print*,'a1 =',a1

end program test

It compiles and works well with ifort, producing the obvious outputs:

*** do : a1 = ext1_t (1,2) ***

 --> ext1EqCl

 

***  do : p = a1 ***

 --> generic_assign

 

*** do : a1 = p ***

 --> ext1EqCl

 a1 =           1           2

 

But it doesn't compile with gfortran, producing the error: Ambiguous interfaces in intrinsic assignment operator for « generic_assign » at (1) and « ext1eqcl » at (2).

If I remove the generic assignment from ext1 and I add the procedure ext1EqCl in the assignment interface as in the following version of typedefs module:

module typedefs
   implicit none

   type base_t
      integer :: i = 0
   end type base_t

   type, extends(base_t) :: ext1_t
      integer :: j = 0
   end type ext1_t

   interface assignment(=)
      module procedure generic_assign
      module procedure ext1EqCl
   end interface

contains

   subroutine generic_assign (lhs, rhs)
      class(base_t), intent(in )              :: rhs
      class(base_t), intent(out), allocatable :: lhs
      print*,'--> generic_assign'
      allocate (lhs, source=rhs)
   end subroutine generic_assign

   subroutine ext1EqCl (lhs, rhs)
      class(base_t), intent(in ) :: rhs
      type (ext1_t), intent(out) :: lhs
      print*,'--> ext1EqCl'
      select type(rhs)
         type is (ext1_t)
            lhs%i = rhs%i ; lhs%j = rhs%j
      end select
   end subroutine ext1EqCl

end module typedefs

it compiles and works well with gfortran but not with ifort ( error #6745: The type/rank signature for the arguments of this specific subroutine matches another specific subroutine that shares the same defined ASSIGNMENT.   [EXT1EQCL]).

Thank you very much for your time.

ps: ifort --version:  ifort (IFORT) 15.0.3 20150408     gfortran --version: GNU Fortran (GCC) 6.3.0

 

 

 

Viewing all 2746 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>