On Mon, Jan 28, 2019 at 08:49:52PM +0100, Thomas König wrote: > > the attached patch fixes a long-time regression where a c_funptr from a > module could not be found. > > The solution is a bit of a hack, but so is our whole implementation of > the C interop stuff. > > Regression-tested. OK for trunk? > > Regards > > Thomas > > 2019-01-28 Thomas Koenig <tkoe...@gcc.gnu.org> > > PR fortran/57048 > * interface.c (gfc_compare_types): If a derived type and an > integer both have a derived type, and they are identical, > this is a C binding type and compares equal.
I don't understand this sentence. How can an INTEGER have a derived type? > > 2019-01-28 Thomas Koenig <tkoe...@gcc.gnu.org> > > PR fortran/57048 > * gfortran.dg/c_funptr_1.f90: New file. > * gfortran.dg/c_funptr_1_mod.f90: New file. > Index: interface.c > =================================================================== > --- interface.c (Revision 268104) > +++ interface.c (Arbeitskopie) > @@ -692,6 +692,15 @@ gfc_compare_types (gfc_typespec *ts1, gfc_typespec > if (ts1->type == BT_VOID || ts2->type == BT_VOID) > return true; > > + /* Special case for our C interop types. There should be a better > + way of doing this... */ > + > + if (((ts1->type == BT_INTEGER && ts2->type == BT_DERIVED) > + || (ts1->type == BT_DERIVED && ts2->type == BT_INTEGER)) > + && ts1->u.derived && ts2->u.derived > + && ts1->u.derived == ts2->u.derived) > + return true; If the above is a test for ISO C binding, shouldn't the test also check (ts1->is_c_interop || ts1->is_iso_c) and similar for ts2? -- Steve
