It is not a "problem" as such just an observation / discussion point. I noted recently (using Gfortran) that it spits out errors when I have c_loc(var) and var has not been given the target (or pointer) attribute. Having checked it would seem that is is correct behaviour.
Ifort seem quite happy to ignore that "problem" even with /stand ( checking the possibility it was allowed as and extension). Clearly ifort makes good code irrespectively.
Additionally taking C_LOC of a function rather than C_FUNLOC seems OK in ifort but is not OK in Gfortran.
Do we consider these to be a defects?
It's not a defect, as the standard doesn't require a processor (compiler) to diagnose this (the rule is neither a numbered syntax rule nor a constraint.) That said, it's a good thing if a processor can diagnose such things and it would be a great suggestion to make to Intel. There are many parts of the standard that ifort does warn about that aren't syntax rules or constraints.
It will be generally useful to customers of Intel Fortran if the compiler issued a warning in situations where the statement in the standard, "X shall have either the POINTER or TARGET attribute," was not conformed to in C_LOC(X) instructions in code.
Your support request along such lines will thus be useful for other customers too.
Sort of related to this, you may have seen in another thread that I attached the ProcessorInfo sample from the Intel samples bundle. I wrote this back in 2012 or 2013 and I thought it was standard-compliant. The current Intel compiler, though, complained about use of C_SIZEOF on a non-interoperable variable, which the older compiler had not. Oops! I fixed that and sent my fixed copy to Intel (it's also the one I attached in the thread.)
The Intel compiler knows about module intrinsics and it can choose to warn about violations of the rules in the standard text.