On Tue, Jan 29, 2019 at 10:12:49PM +0100, Thomas König wrote: > Hi Steve, > > >> 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? > > ISO C handling is a bit of a mess. Of course. > The original tree has > > symtree: 'C_funptr' || symbol: 'c_funptr' > type spec : (DERIVED c_funptr C_INTEROP ISO_C) > attributes: (DERIVED BIND(C) USE-ASSOC(__iso_c_binding)) > components: > (c_address (INTEGER 8 C_INTEROP) () PRIVATE) > > and we somehow later lose the derived type stuff and use a naked > integer. The problem appears to be that the module is written out > when that conversion has not yet happened. > > So, the C_funptr (capitalized because it is a derived type) is > written to the module file, and later compared to c_funptr upon > module reading. Hilarity ensues, and we cannot use a C function > pointer from a module, the topic of the PR.
Ugh. Thanks for the explanation. > >> 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. > > > > Yep, this is a rather messy fix to a messy situation. I think the > C interop stuff could do with a thorough redesign, but that's > not going to happen for gcc 9. > > So, I think this is about the best we can do - at least it gets the > bug fixed. If you want me to put in a FIXME, I'll gladly do this. > Perhaps, add the PR number to the comment in code so history of why this is a special case can be found. I'll leave up to you on adding a "FIXME: If ISO C Binding support is ever rewritten, this should be revisted" or some such phrasing. Thanks for the patch, and OK to commit. -- Steve 20170425 https://www.youtube.com/watch?v=VWUpyCsUKR4 20161221 https://www.youtube.com/watch?v=IbCHE-hONow
