Bug 33497 - Bind(C): C_LOC rejects interoperable arguments
Summary: Bind(C): C_LOC rejects interoperable arguments
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: rejects-valid
Depends on:
Blocks: 32630
  Show dependency treegraph
Reported: 2007-09-19 12:16 UTC by Tobias Burnus
Modified: 2007-09-20 11:54 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2007-09-19 12:16:55 UTC
See http://gcc.gnu.org/ml/fortran/2007-09/msg00301.html
for the initial bug report by Salvatore Filippone (thanks for finding the bug!)
and a longer example.

Assume the following code:

  type double_vector_item
    real(c_double), allocatable :: v(:)
  end type double_vector_item
  type(double_vector_item), target :: dbv_pool

While V(:) itself is does not have the TARGET attribut, dbv_pool%v has it due to the following clause in the Fortran 2003 standard (" TARGET attribute"):

"If an object has the TARGET attribute, then all of its nonpointer subobjects also have the TARGET attribute."

Additionally, "real(c_double)" is of interoperable type and kind; thus the following clause of " C LOC (X)" applies to dbv_pool%v:

"Argument. X shall [...] (1) have interoperable type and type parameters and be [...] (b) an allocated allocatable variable that has the TARGET attribute and is not an array of zero size".

I did not investigate in detail, but gfortran seems to fail (in resolve.c's gfc_iso_c_func_interface) at

          /* See if we have interoperable type and type param.  */
          if (verify_c_interop (&(args->expr->symtree->n.sym->ts),
                                &(args->expr->where)) == SUCCESS
              || gfc_check_any_c_kind (&(args_sym->ts)) == SUCCESS)

- dbv_pool itself is not C interoperable as it has no BIND(C) - at it cannot have this attribute at V is allocatable.
- V cannot have an explicit TARGET attribute as it is a TYPE component
- sunf95 has the same problem as gfortran, but ifort 10, NAG f95 and g95 accept this program.
Comment 1 Salvatore Filippone 2007-09-19 17:29:44 UTC
A version with an inner pointer to a derived type instead of allocatable array fails as well.
module c_vhandle_mod
  use iso_c_binding
  type foo
    integer :: i
  end type foo  
  type foo_item
    type(foo), pointer  :: v=> null()
  end type foo_item
  type(foo_item), allocatable :: foo_pool(:)


  type(c_ptr) function get_foo_address(handle)
    integer(c_int), intent(in) :: handle    
    get_foo_address = c_loc(foo_pool(handle)%v)    
  end function get_foo_address
end module c_vhandle_mod
[sfilippo@localhost bugtest]$ /usr/local/gcc43/bin/gfortran -c c_vh_2_mod.f90 

    get_foo_address = c_loc(foo_pool(handle)%v)
Error: Parameter 'foo_pool' to 'c_loc' at (1) must be either a TARGET or an associated pointer

Comment 2 patchapp@dberlin.org 2007-09-19 23:15:20 UTC
Subject: Bug number PR 33497

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01583.html
Comment 3 Tobias Burnus 2007-09-20 11:50:51 UTC
Subject: Bug 33497

Author: burnus
Date: Thu Sep 20 11:50:39 2007
New Revision: 128620

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128620
2007-09-20  Christopher D. Rickett  <crickett@lanl.gov>

        PR fortran/33497
        * resolve.c (gfc_iso_c_func_interface): Use information from
        subcomponent if applicable.

2007-09-20  Christopher D. Rickett  <crickett@lanl.gov>

        PR fortran/33497
        * gfortran.dg/c_loc_tests_11.f03: New test case.


Comment 4 Tobias Burnus 2007-09-20 11:54:58 UTC
Fixed on 4.3 (trunk).