pointer value function return, contiguous, ifort 18.0, bug??

[may_ka]

Hi there.

This code:

Module Test_Parent
  Type, abstract :: Parent
  contains
    Procedure(FunGetPt), Pass, Deferred :: getPt
  End type Parent
  Abstract Interface
    Function FunGetPt(this)
      Import parent
      Class(parent), Intent(In), Target :: this
      Real, Pointer :: FunGetPt(:,:)
    End Function FunGetPt
  End Interface
  Type, extends(parent) :: Progeny
    Real, allocatable :: a(:,:)
  contains
    Procedure, Pass :: getPt => FunGetPt_Pr
  End type Progeny
contains
  Function FunGetPt_Pr(this)
    Class(progeny), Intent(In), Target :: this
    Real, Pointer :: FunGetPt_Pr(:,:)
    FunGetPt_Pr=>this%a
  End Function FunGetPt_Pr
End Module Test_Parent
Program PP
  use Test_Parent, only: progeny
  Implicit None
  Type(progeny), Target :: a
  Real, Pointer, contiguous :: b(:,:)=>null()
  allocate(a%a(10,10),source=10.0)
  b=>a%getPt()
End Program PP

yields

Test.f90(31): error #5558: A pointer with the CONTIGUOUS attributes is being made to a non-contiguous target
  b=>a%getPt()
--^
compilation aborted for Test.f90 (code 1)

when compiled with 18.0 and

ifort -o0 -check all Test.f90

It runs when using 17.4.

Is that a Bug??

Cheers

[Lorri_M_Intel]

In 18.0 we added "check contiguous" to the list of checks done by "check all", so in 17.0 this wasn't being checked for, which is why you didn't see it before.

That said, let's look at what the compiler "knows" when it is checking for contiguity at line 31.  It knows that B is contiguous.   However, all it knows about the function return value for getpt is that it is a pointer.    While it is true that the actual implementation of the routine points that pointer to an allocatable, the signature of the routine indicates that the pointer could be non-contiguous.

 Does that make sense?

                          --Lorri

[FortranFan]

Lorri Menard (Intel) wrote:

In 18.0 we added "check contiguous" to the list of checks done by "check all",..    While it is true that the actual implementation of the routine points that pointer to an allocatable, the signature of the routine indicates that the pointer could be non-contiguous.

 Does that make sense?

Hello Lorri,

Yes, but a couple of concerns I have:

1. Is not /check option a run-time check rather than a compiler-time error?
2. Should not the following variation where the function return is defined to be CONTIGUOUS (and where the caller has the interface information available) pass the Intel Fortran "check contiguous" test?  However the compiler 18.0 still issues an error.

Module Test_Parent
  Type, abstract :: Parent
  contains
    Procedure(FunGetPt), Pass, Deferred :: getPt
  End type Parent
  Abstract Interface
    Function FunGetPt(this)
      Import parent
      Class(parent), Intent(In), Target :: this
      Real, Pointer, contiguous :: FunGetPt(:,:)  !<-- Note CONTIGUOUS attribute
    End Function FunGetPt
  End Interface
  Type, extends(parent) :: Progeny
    Real, allocatable :: a(:,:)
  contains
    Procedure, Pass :: getPt => FunGetPt_Pr
  End type Progeny
contains
  Function FunGetPt_Pr(this)
    Class(progeny), Intent(In), Target :: this
    Real, Pointer, contiguous :: FunGetPt_Pr(:,:) !<-- Note CONTIGUOUS attribute
    FunGetPt_Pr=>this%a
  End Function FunGetPt_Pr
End Module Test_Parent
Program PP
  use Test_Parent, only: progeny
  Implicit None
  Type(progeny), Target :: a
  Real, Pointer, contiguous :: b(:,:)=>null()
  allocate(a%a(10,10),source=10.0)
  b=>a%getPt()
End Program PP

By the way, there is another issue with Intel compiler that when the function result attribute in the overriding procedure of FunGetPt_Pr has a mismatch with the signature of the deferred procedure, no errors or warnings are issued.  I'll submit this as incident at the OSC.

Thanks,

[may_ka]

Thanks FortranFan for pointing that out.

I was about to post the same variation of the example. With that the compiler "knows" everything at compile time. Form my understanding it should work.

cheers

[Lorri_M_Intel]

RE: FortranFan

First - hmm, yes, I'd expect that program to compile successfully.  I've shared it internally, but to be sure that it gets on official work lists, could you use OSC?  I appreciate that.

Second, while it is true that most of the "check" options are run-time (we put the check options under "Runtime checking" in the property pages after all) the actual implementation is slightly blurred.  One example of this is bounds checking.  If you write a program with an obvious compile-time bounds digression, it's not reported unless you've specified check:bounds.

[FortranFan]

Lorri Menard (Intel) wrote:

..  I've shared it internally, but to be sure that it gets on official work lists, could you use OSC?  I appreciate that.

Second, while it is true that most of the "check" options are run-time (we put the check options under "Runtime checking" in the property pages after all) the actual implementation is slightly blurred.  One example of this is bounds checking.  .. 

Hello Lorri,

As you suggested, support request #03057839 has been submitted at the OSC.  And I have included a reference to this thread also.   A variant of the problem included is this:

   integer, pointer, contiguous :: foo(:)
   foo => f()
contains
   function f() result( fp )
      integer, pointer, contiguous :: fp(:)
      allocate (fp(42))
   end function
end

xx>ifort /c /standard-semantics /warn:all /check:all p.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.0.124 Build 20170811
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

p.f90(2): error #5558: A pointer with the CONTIGUOUS attributes is being made to
 a non-contiguous target
   foo => f()
---^
compilation aborted for p.f90 (code 1)

Thanks much for your clarification on the "check" options.

[Ron_Green]

this bug was fixed in late 2017, in the 19.0 compilers and later updates to 18.0