Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

/Stand C_LOC and Target Attribute

andrew_4619
Honored Contributor II
899 Views

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?

0 Kudos
7 Replies
Steve_Lionel
Honored Contributor III
885 Views

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.

0 Kudos
FortranFan
Honored Contributor II
880 Views

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.

  

0 Kudos
Robert_van_Amerongen
New Contributor III
863 Views

I fully agree with FortranFan.

 

Robert

0 Kudos
andrew_4619
Honored Contributor II
847 Views
Steve_Lionel
Honored Contributor III
843 Views

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.

0 Kudos
andrew_4619
Honored Contributor II
836 Views

yes I fell foul of c_sizeof a few weeks (months?) back for the same reason.

0 Kudos
andrew_4619
Honored Contributor II
789 Views

"I escalated this to our development team as a Feature Request (CMPLRIL0-33498). It should be implemented in our future compiler versions. Regards, Igor, Intel Developer Products Support"

Just to add this note.

0 Kudos
Reply