Internal pure procedure with side effect

Dear all,
a pure procedure internal to a subroutine should not be able to modify the variables of its parent subroutine (apart, of course, from those passed to it as arguments with the intent (in)out). This is what gfortran signals in the example below, but not ifort or nagfor. Why?

module foo_m
   implicit none
contains

   subroutine foo ( a, b )
      integer, intent(in out) :: a, b
      b = 0
      call sbar ( a )
      b = fbar ( a )
   contains
   
      pure subroutine sbar ( a )
         integer, intent(out) :: a
         a = b
         b = 1 ! <- shouldn't the compiler report an error? 
               !    (gfortran does, but not nagfor or ifort)
      end subroutine sbar
      
      pure function fbar ( a ) result( r )
         integer, intent(in) :: a
         integer             :: r
         r = a+b
         b = 2 ! <- same here
      end function fbar
   
   end subroutine foo
end module foo_m

It seems logical to me that gfortran gives:

gfortran foo_m.f90 -c
foo_m.f90:23:9:

   23 |          b = 2 ! <- same here
      |         1
Error: Variable 'b' cannot appear in a variable definition context (assignment) at (1) in PURE procedure
foo_m.f90:15:9:

   15 |          b = 1 ! <- shouldn't the compiler report an error?
      |         1
Error: Variable 'b' cannot appear in a variable definition context (assignment) at (1) in PURE procedure

But why don’t ifort and nagfor?

Seems to be a bug that should be reported.

I’ve noticed ifort’s failure to report pure procedure’s side-effects, but mostly when pointer components and procedure pointer components are involved.

Since ifort is deprecated now, the issue should be reported against ifx. With it, your code still seems to compile successfully:

$ ifx -V -c -stand f23 -standard-semantics /media/vmshare/pure-side-effect.f90 && echo OK
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2025.0.1 Build 20241113
Copyright (C) 1985-2024 Intel Corporation. All rights reserved.

 Intel(R) Fortran 25.0-1205.1
OK
1 Like

I think this code violates C15104 part (1) of section 15.7. Since it is a constraint, I think the compiler is required to detect the error. Maybe others can verify this interpretation.

2 Likes

Thank you for your reply and comment.
I have reported this issue to NAG and intel.