Community
cancel
Showing results for 
Search instead for 
Did you mean: 
JamesWright
Beginner
124 Views

Missing Warning/error using undefined INTENT(OUT) dummy argument

Jump to solution

I believe there is a missing warning/error in the following code:

program main                                 
  real*8 :: foo, bar                         
                                             
  bar = 1.0d0                                
                                             
   call intentOutSub(foo, bar)               
                                             
   contains                                  
      subroutine intentOutSub(foosub, barsub)
        real*8, intent(out) :: foosub        
        real*8, intent(inout) :: barsub      
                                             
        barsub = foosub                      
        foosub = barsub                      
                                             
      end subroutine intentOutSub            
end program                                  

 

From Intel Documentation for INTENT :

OUT
Specifies that the dummy argument will be used to pass data from the procedure back to the calling program. The dummy argument is undefined on entry, although it may have subcomponents that are initialized by default. An undefined argument must be defined before it is referenced in the procedure. (emphasis added)
Any associated actual argument must be definable.


So in the above procedure, `foosub` is an undefined variable with `INTENT(OUT)` and is reference in the procedure (during the assignment of `barsub`) before it is defined. 
However, this compiles without any error or warning on "ifort version 2021.1 Beta". Shouldn't this be an error, or at least a warning?

 

Labels (2)
0 Kudos

Accepted Solutions
Steve_Lionel
Black Belt Retired Employee
108 Views

Ideally, yes, but the Intel compiler does not do control flow uninitialized variable detection. It will warn you if you NEVER assign to an INTENT(OUT) dummy, but any assignment, including one where the expression is undefined, will suppress that warning.

The wording of the standard makes it the program's responsibility not to reference an undefined object. The compiler is not required to detect this, though it's always goodness if it can.

View solution in original post

6 Replies
Steve_Lionel
Black Belt Retired Employee
109 Views

Ideally, yes, but the Intel compiler does not do control flow uninitialized variable detection. It will warn you if you NEVER assign to an INTENT(OUT) dummy, but any assignment, including one where the expression is undefined, will suppress that warning.

The wording of the standard makes it the program's responsibility not to reference an undefined object. The compiler is not required to detect this, though it's always goodness if it can.

View solution in original post

JamesWright
Beginner
97 Views

"The wording of the standard makes it the program's responsibility not to reference an undefined object."

I'm guessing that's in the ISO (not public) language spec?

Steve_Lionel
Black Belt Retired Employee
92 Views

Yes, but you can read what the committee uses - https://j3-fortran.org/doc/year/18/18-007r1.pdf

The specific wording I reference is this:

A reference is permitted only if the variable is defined.

9.2 paragraph 2.

 
JamesWright
Beginner
82 Views

Ah, sweet! I've been looking for some official reference document. Thanks!!

JamesWright
Beginner
72 Views

Reading through the standard document, the part that sticks out to me is 8.5.10 ¶3:

The INTENT (OUT) attribute for a nonpointer dummy argument specifies that the dummy argument becomes undefined on invocation of the procedure,

So the INTENT(OUT) dummy variable should be treated as undefined upon entry to the subroutine.
This is further backed up in 19.6.5 ¶1(6):


A reference to a procedure causes an entire dummy data object to become defined if the dummy data object does not have INTENT (OUT)


But, there is nothing in the specification about the legality of having an undefined variable in the expr side of an implicit assignment statement (section 10.2.1.1, R1032). I think that'd generally be a nice warning to throw, but not a requirement by the specification. (I have absolutely no experience/understanding of compilers, so I'm not sure if it even keeps track of variable defined-ness explicitly).

Steve_Lionel
Black Belt Retired Employee
65 Views

The reference I cited applies to that.