C interoperability and C_LOC intrinsic
David Car
david.car7@gmail.com
Sun Sep 19 09:59:00 GMT 2010
Hi Thomas,
My apologies. In my haste, I was just trying to put together a
demonstrative example and not a compilable one to illustrate what I
was trying to convey. But what an horrible example! Please forgive
me for this. Here is a complete example that is compilable that will
illustrate the error:
program test
use ISO_C_BINDING
interface
subroutine my_c_func( a ) bind( C, name="my_c_func" )
use, intrinsic :: ISO_C_BINDING
type (c_ptr), value :: a
end subroutine my_c_func
end interface
real, dimension(:), allocatable, target :: A
real, dimension(:), pointer :: B
allocate( A( 20 ) )
B => A
call my_c_func( c_loc( A ) )
call my_c_func( c_loc( B ) )
deallocate( A )
end program test
It really boils down to my interpretation of the latest standard which
is most likely in error. The ISO/IEC SC22/WG5/N1776 document, in
section 15.2.3.6, that I have states for the C_LOC intrinsic:
" 3 Argument. X shall have either the POINTER or TARGET attribute. It
shall not be a coindexed object. It shall
either be a variable with interoperable type and kind type parameters,
or be a scalar, nonpolymorphic variable
with no length type parameters. If it is allocatable, it shall be
allocated. If it is a pointer, it shall be associated.
If it is an array, it shall be contiguous and have nonzero size. It
shall not be a zero-length string."
So, it seems that the interpretation is that an argument with the
POINTER attribute can only be a scalar. This is enforced while
looking through resolve.c at the following code snippet from the
gfc_iso_c_func_interface function:
else if (arg_attr.pointer
&& is_scalar_expr_ptr (args->expr) != SUCCESS)
{
/* Case 1c, section 15.1.2.5, J3/04-007: an
associated
scalar pointer. */
gfc_error_now ("Argument '%s' to '%s' at %L must be an "
"associated scalar POINTER", args_sym->name,
sym->name, &(args->expr->where));
retval = FAILURE;
}
I guess it centers around the "interoperable" type characteristic. So
an associated pointer to an array is considered not interoperable? I
could say why this could be the case because you could have an
instance where your are viewing just a slice of the array with the
pointer, but I would rely on the programmer to make that assurance.
Also, since the pointer must be associated, this could be know at
compile time? Regardless, the latest version of ifort compiles the
example just fine, so Intel's interpretation is different than
gfortran. Ultimately, I'm just looking for some clarification.
Please tell me if you think this workaround is acceptable (this does
compile with gfortran):
program test
use ISO_C_BINDING
interface
subroutine my_c_func( a ) bind( C, name="my_c_func" )
use, intrinsic :: ISO_C_BINDING
type (c_ptr), value :: a
end subroutine my_c_func
end interface
real, dimension(:), allocatable, target :: A
real, pointer :: B
allocate( A( 20 ) )
B => A( 1 )
call my_c_func( c_loc( A ) )
call my_c_func( c_loc( B ) )
deallocate( A )
end program test
Do you see any inherent problems here?
I also want to say great job on 4.6. I've been compiling almost
weekly from the repo and the new polymorphic features are working
wonderfully. gfortran has become my workhorse. Recent timing tests
that I've done have gfortran is beating the other compilers hands
down.
Regards,
David
On Sat, Sep 18, 2010 at 6:08 PM, Thomas Koenig <tkoenig@netcologne.de> wrote:
> Am Samstag, den 18.09.2010, 11:22 -0400 schrieb David Car:
>> I was trying out the ISO_C_BINDINGS module and the use of the C_LOC
>> intrinsic. I thought that the standard allowed either an allocatable
>> or pointer as the argument to C_LOC. For instance,
>>
>> program main
>>
>> real, allocatable, dimension(:) :: A
>> real, pointer, dimension(:) :: p_A
>>
>> allocate( A )
>> p_A => A
>>
>> call my_c_func( c_loc( A ) )
>> call my_c_func( c_loc( p_A ) )
>>
>> deallocate( A )
>>
>> end program
>
> This program contains at least two errors (missing TARGET on A
> and missing dimension spec in the allocate statement).
>
> Can you show us a program that we could use to reproduce the
> behavior you are describing?
>
> Thomas
>
>
More information about the Fortran
mailing list