Hi Thomas,
Am 24.03.25 um 22:28 schrieb Thomas Koenig:
Hi Harald,
the attached patch contains a chunk changing resolve.cc
that is neither described in the suggested commit message,
and it fails to compile here:
../../gcc-trunk/gcc/fortran/resolve.cc: In function 'void
check_c_funptr_assign_interface(gfc_expr*, gfc_expr*)':
../../gcc-trunk/gcc/fortran/resolve.cc:12248:48: error: 'gfc_expr' {aka
'struct gfc_expr'} has no member named 'is_c_interop'
12248 | if (rhs->expr_type != EXPR_FUNCTION || !rhs->is_c_interop)
| ^~~~~~~~~~~~
Can you please check whether you inadvertently added something
that was not planned or tested?
I sent out the wrong version of the patch, sorry (one which contained
an intermediate stage of something I tried, and then abandoned).
Here is the one that actually in my tree, and that I regression-tested.
this is better.
Two things:
+/* Write out an interoperable function returning a function pointer.
Better
+ handled separately. As we know nothing about the type, assume
+ a C default return of int. */
+
+static void
+write_funptr_fcn (gfc_symbol *sym)
+{
+ fprintf (dumpfile, "void (*%s (", sym->binding_label);
The comment does not match the code: the return type is (void *),
isn't it?
Second:
+ if (sym->ts.type == BT_DERIVED
+ && strcmp (sym->ts.u.derived->name, "c_funptr") == 0)
Wouldn't it be better to test for:
sym->ts.u.derived->intmod_sym_id == ISOCBINDING_FUNPTR
so that we do not accidentally handle a user-defined type
of same name and bind(c)?
OK with the above addressed.
Thanks for the patch!
Harald
Best regards
Thomas
