http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46974
--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu>
2010-12-18 17:10:59 UTC ---
On Sat, Dec 18, 2010 at 10:07:51AM +0000, burnus at gcc dot gnu.org wrote:
>
> --- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2010-12-18
> 10:07:33 UTC ---
> (In reply to comment #3)
> > + if ((mold->expr_type == EXPR_VARIABLE || mold->expr_type ==
> > EXPR_STRUCTURE)
> > + && mold->ts.type == BT_DERIVED && mold->ts.u.derived
> > + && (strcmp(mold->ts.u.derived->name, "c_ptr") == 0
> > + || strcmp(mold->ts.u.derived->name, "c_funptr") == 0))
> > + return NULL;
> > +
>
> Won't this cause problems with user-defined types with the same name?
A check for mold->ts.u.derived->attr.is_iso_c could be added, but
yes I agree that this appears to somewhat hackish. In fact, the
patch fails in a interesting way with a new piece of code from
James.
program bug6
use ISO_C_BINDING
implicit none
interface
function fun()
use ISO_C_BINDING
implicit none
type(C_FUNPTR) fun
end function fun
end interface
type(C_PTR) array(2)
type(C_FUNPTR) result
integer(C_INTPTR_T), parameter :: const(*) = [32512,32520]
result = fun()
array = transfer([integer(C_INTPTR_T)::32512,32520],array)
! write(*,*) transfer(result,const)
! write(*,*) transfer(array,const)
end program bug6
function fun()
use ISO_C_BINDING
implicit none
type(C_FUNPTR) fun
fun = transfer(32512_C_INTPTR_T,fun)
end function fun
With this code, mold->ts.type is BT_INTEGER, the backend_decl
is NULL, and mold->ts.u.derived contains the information that
we need.
So, yes, creating a proper backend_decl when C_PTR or C_FUNPTR
is parsed/resolved is probably the correct solution. Unfortunately,
I don't know how or where to do that. :(
