Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
FPGA community forums and blogs on community.intel.com are migrating to the new Altera Community and are read-only. For urgent support needs during this transition, please visit the FPGA Design Resources page or contact an Altera Authorized Distributor.

integer(8) causes array temperary

abhimodak
New Contributor I
752 Views

Hi

In the sample below: changing integer to integer(8) is giving an array-temporary. Is standard violated by the program (in subroutine Method's argument declarations for arrays A and B)?

Compile with "ifort /check:arg_temp_created". I am using XE 2015 Update 2 package 179 with VS2012.

Abhi

---

   Module OM
      Implicit None
      !Integer :: KK
      Integer(8) :: KK
   Contains
      Subroutine Method(A, B)
         Real(8), Intent(INOUT) :: A(KK,KK), B(KK)
         A = 0.0d0; B = 1.0d0
      End Subroutine Method
   End Module OM
   
   Module Shree
      Use OM
   Contains
      Subroutine Set(C)
         Real(8), Intent(IN), Target :: C(KK*KK+KK)
         Real(8), Pointer :: pC(:) => Null()
         pC => C
         Call Method(pC(1:), pC(KK*KK+1:))
      End Subroutine Set
   End Module Shree
   
   Program Test
      Use Shree
      Implicit None
      Real(8), Allocatable :: C(:)
      
      Print *, "Give KK"
      Read *, KK
      Allocate(C(KK*KK + KK))
      Call Set(C)
      Print *, C(KK)
   End Program Test

0 Kudos
8 Replies
Steven_L_Intel1
Employee
752 Views

There's nothing wrong with your code. Adjustable arrays are classic Fortran (though the use of host association is a bit newer.) The compiler is being a bit stupid here - I will let the developers know. Since pC is a pointer, the run-time code does have to check for contiguity, but apparently the use of an INTEGER(8) subscript throws it off.

0 Kudos
Steven_L_Intel1
Employee
752 Views

Well, there IS something wrong with your code, but it doesn't change the fact that the compiler is being silly.

Subroutine Method changes the value of Set's dummy argument C through both the A and B dummy arguments. Because A and B don't have TARGET, this violates the following restriction in the standard (12.5.2.13p1(3)):

While an entity is associated with a dummy argument, the following restrictions hold.
Action that affects the value of the entity or any subobject of it shall be taken only through the dummy argument unless

  (a) the dummy argument has the POINTER attribute or
  (b) the dummy argument has the TARGET attribute, the dummy argument does not have INTENT (IN), the dummy argument is a scalar object or an assumed-shape array without the CONTIGUOUS attribute, and the actual argument is a target other than an array section with a vector subscript.

However, adding TARGET to A and B doesn't change the behavior. Issue ID is DPD200379423.

0 Kudos
jimdempseyatthecove
Honored Contributor III
752 Views

Wouldn't C in PROGRAM also require TARGET?

Jim Dempsey

0 Kudos
Steven_L_Intel1
Employee
752 Views

I don't think so. The restrictions are on the dummy argument.

0 Kudos
JVanB
Valued Contributor II
752 Views

What about the part where it says "and the actual argument is a target"?

 

0 Kudos
abhimodak
New Contributor I
752 Views

Hi

I noticed this after posting the example -- There should be Intent(INOUT) for C in subroutine Set.

Abhi

0 Kudos
Steven_L_Intel1
Employee
752 Views

This issue has been fixed for the next major release, due out in the second half of 2016. The compiler will then consider additional types of expressions for generating the run-time contiguity check.

0 Kudos
jimdempseyatthecove
Honored Contributor III
752 Views

>>The compiler will then consider additional types of expressions for generating the run-time contiguity check.

Yea! I hope it catches all instances of unnecessary array temporaries.

Jim Dempsey

0 Kudos
Reply