C_LOC-related problem with ifort 2011.3

C_LOC-related problem with ifort 2011.3

Hello,

the following code snippet creates a warning when compiled with interface-checking enabled (Intel Visual Fortran 2011.3.175, VS2008).

The warning goes away if the stub subroutine "sub1" is removed.

[fxfortran] subroutine sub1 end subroutine sub2(values) use,intrinsic :: ISO_C_BINDING implicit none integer values ! needed for referencing integer rval interface function test(param_values) bind(C) use,intrinsic :: ISO_C_BINDING implicit none integer(C_INT) :: test type(C_PTR), value :: param_values end function test end interface rval = test(C_LOC(values)) end [/fxfortran]

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Compilers other than ifort, of course, will reject this on account of the missing TARGET attribute. I don't get such a warning:
$ ifort -gen-interfaces -c stro.f
Intel Visual Fortran Intel 64 Compiler XE for applications running on Inte
l 64, Version 12.0.3.175 Build 20110309
Copyright (C) 1985-2011 Intel Corporation. All rights reserved.

$

On Win7 I get that warning, reduced command line is
ifort /warn:interfaces /c Console1.f90

(I'm not sure if -gen-interfaces under Linuxdoes already produce the warnings).

Thanks - I can reproduce this and will escalate to the developers. Issue ID is DPD200167922.

The lack of the warning for C_LOC I understand. Yes, it would be nice if ifort would give a diagnostic for the lack of TARGET. We have some changes in mind that would allow us to do that.

Steve

Thank you, this is really appreciated.

I'm well aware that the posted (reduced) code is far from nice, but it's the most direct (probably only)way I've found to port some existing routines. They are trying to interface between
real,dimension(:),pointer :: valued => Null() (which is later allocated)
and the void* on the C-side, and my understanding of the ISO_C_BINDING methods used to describe the interfacing are quite limited so I'm happy that it works at all and makes sense to me.

Thanks again.

This was fixed in the 12.1 compiler.

Steve

Login to leave a comment.