- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Escalated as DPD200358966. I also discovered that if the dummy argument is made to be fixed-shape, stack is corrupted. This was separately escalated.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page