Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

VALUE attribute has no value?

IanH
Honored Contributor III
1,076 Views
PROGRAM DubiousValues
  IMPLICIT NONE
  LOGICAL :: array(3)
  !****
  array = .TRUE.
  PRINT "('Before:',*(L1,:,1X))", array
  CALL proc(array)
  PRINT "('After :',*(L1,:,1X))", array
CONTAINS
  SUBROUTINE proc(arg)
    LOGICAL, VALUE :: arg(:)
    !****
    arg = .FALSE.
  END SUBROUTINE proc
END PROGRAM DubiousValues

arg should be associated with an anonymous data object that has the value of array (but not actually associated with array), etc.  But...

>ifort /check:all /warn:all /standard-semantics "2014-07-22 DubiousValues.f90" && "2014-07-22 DubiousValues.exe"
Intel(R) Visual Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 15.0.0.070 Beta Build 20140530
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

"-out:2014-07-22 DubiousValues.exe"
-subsystem:console
"2014-07-22 DubiousValues.obj"
Before:T T T
After :F F F


 

0 Kudos
5 Replies
mecej4
Honored Contributor III
1,076 Views

F2003, C527 (R501) : If the VALUE attribute is specified, the PARAMETER, EXTERNAL, POINTER, ALLOCATABLE, DIMENSION, VOLATILE, INTENT(INOUT), or INTENT(OUT) attribute shall not be specified. 

Should the compiler not detect that VALUE precludes DIMENSION for a dummy argument?

0 Kudos
IanH
Honored Contributor III
1,076 Views

The restriction on DIMENSION and VALUE has been lifted in F2008 (I'd forgotten that the restriction existed previously).  Perhaps the compiler's left error checking foot got a bit ahead of its right implementation foot.
 

0 Kudos
Steven_L_Intel1
Employee
1,076 Views

Interesting. I wonder if the assumed-shape threw it off. We'll look into this.

A couple of things of note. One is that in 15.0 we changed the default so that VALUE with a non-BIND(C) routine passes an anonymous copy by reference, rather than passing by value as the compiler had done earlier. You can get the old behavior back with /assume:nostd_value.

Second, though it isn't relevant here, if the procedure is BIND(C), only scalars may have the VALUE attribute - this was clarified in an interpretation. The new wording is (emphasis mine):

"any scalar dummy argument with the VALUE attribute is interoperable with the corresponding formal parameter of the prototype"

0 Kudos
Steven_L_Intel1
Employee
1,076 Views

Escalated as DPD200358966. I also discovered that if the dummy argument is made to be fixed-shape, stack is corrupted. This was separately escalated.

0 Kudos
Steven_L_Intel1
Employee
1,076 Views

The reported issue has been fixed - I think the fix will be in 16.0.1 but I am not certain of that. If not, then Update 2.

0 Kudos
Reply