Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

/Stand C_LOC and Target Attribute

andrew_4619
Honored Contributor I
301 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
Black Belt Retired Employee
287 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.

FortranFan
Honored Contributor II
282 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.

  

Robert_van_Amerongen
New Contributor III
265 Views

I fully agree with FortranFan.

 

Robert

andrew_4619
Honored Contributor I
249 Views
Steve_Lionel
Black Belt Retired Employee
245 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.

andrew_4619
Honored Contributor I
238 Views

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

andrew_4619
Honored Contributor I
191 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.

Reply