https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96018
--- Comment #12 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
I don't have a debuggable source here at the moment, but I think there
may be a problem with implicit_pure, which was either introduced by
a patch in the range that Dominique provided (maybe for PR 85599?), or
exposed by something in the middle end.
The problem can be seen with -fdump-tree-original (in my case, with 9.3.0):
Namespace: A-Z: (UNKNOWN 0)
procedure name = wrapper
symtree: 'call_side_effect'|| symbol: 'call_side_effect'
type spec : (INTEGER 4)
attributes: (PROCEDURE MODULE-PROC FUNCTION)
result: ierr
symtree: 'inner_3d' || symbol: 'inner_3d'
type spec : (INTEGER 4)
attributes: (PROCEDURE MODULE-PROC FUNCTION)
result: ierr
Formal arglist: array
symtree: 'inner_4d' || symbol: 'inner_4d'
type spec : (INTEGER 4)
attributes: (PROCEDURE MODULE-PROC FUNCTION IMPLICIT_PURE)
result: ierr
Formal arglist: array
IMPLICIT_PURE should not be set on inner_4d, because it evaluates the
function call_side_effect (and marking is as PURE is correctly rejected
because of that).
It is also strange that inner_3d is not also wrongly marked as
IMPLICIT_PURE, I do not really see a significant difference between
integer function inner_3d(array) result(ierr)
real, intent(in) :: array(:,:,:)
integer dimensions(3)
dimensions = shape(array)
ierr = call_side_effect()
end function inner_3d
and
integer function inner_4d(array) result(ierr)
real, intent(in) :: array(:,:,:,:)
integer dimensions(4)
dimensions = shape(array)
ierr = call_side_effect()
end function inner_4d
