In Fortran 2018 all of the constraints listed that apply to a "pure" subprogram are so-called numbered constraints (F2018, 15.7 p.2). This means that the compiler is required to be able to diagnose violations of any such constraint. (In practice, there's little motivation for a compiler to choose to let the programmer off the hook and allow such violations.) A violation of a numbered constraint does not need to be diagnosed at compile-time (instead of run-time), although that's generally the time it would be.
However, the constraints that apply to a "pure" subprogram are not necessarily those that are required to make the subprogram pure in a pure computer science sense.
There is a complementary question which can also be addressed here. The constraints I mention apply to pure subprograms, but these aren't the only places where a programmer can mark a procedure to be pure.
The constraints on pure subprograms apply where we have something we want to compile:
function f(x, y, z)
...
end function
Adding the PURE prefix to give instead
pure function f(x, y, z)
...
end function
is where assessment of the constraints would be expected: something which makes PURE inappropriate for f will elicit complaints.
Consider, though:
subroutine s(f)
interface
pure function f(x,y,z)
...
end function f
end interface
end subroutine s
Here we can add the PURE prefix to the dummy procedure's interface block. But we aren't defining a subprogram here and so the numbered constraints don't apply: we can't expect a compiler to check whether the actual argument procedure is pure. There is no numbered constraint (or syntax rule) which says the interface block must be correct for the ultimate use. That's our responsibility as a programmer, and one the compiler may trust we give take seriously. Your compiler will make a good stab at checking and pick up many cases, but it doesn't have to account for our wilful desire to obfuscate.
