Need help with vptr copy function calls

FX fxcoudert@gmail.com
Sat Sep 5 22:01:49 GMT 2020


Hi Tobias, hi everyone,

I am proposing a patch below. My first patch to gfortran in a long time (one commit in 2018, a couple in 2016)!


> Then, probably the procedure-pointer is not properly setup. The component
> is setup in class.c – cf. below "Add component _copy." and that's turned
> into a procedure-pointer in  trans-types.c –  I think in gfc_get_ppc_type.
> It seems as if there the explicit interface is not properly used.

Thanks, that’s exactly what I needed. In gfc_get_ppc_type(), for the copy field of the vptr, it does not find an explicit interface, so probably this is one way we could fix it. But there is also code which is supposed to handle the case of no explicit interface, using only the return value and an unknown arg list (K&R type). It shows that it was the intent of the author of that function was to use the fact that the compiler can work with an unknown arg list. This was introduced by Paul T and Janus in 2009 (https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=37513ce90a7fa5730028c01850bcd983995b7063).

Except it’s not doing it correctly. It’s using:

  build_function_type_list (t, NULL_TREE)

to create the function type, but that’s wrong. That’s for a function type with a known empty arg list, i.e., in C terms:

  (*f)(void)

What we want instead is a K&R prototype, i.e., a function that has unknown arg list:

  (*f)()

which is obtained by:

build_function_type (t, NULL_TREE)

I had to read tree.c a couple of times to make sure I understood it right, so I think the potential for confusion is natural (it’s not an function call we use every day).

So… we can probably fix the fields by adding explicit interfaces to them, but… it works without. So I propose the following fix:


diff --git a/gcc/fortran/trans-types.c b/gcc/fortran/trans-types.c
index d38aa2865ae..c0a77c54f4f 100644
--- a/gcc/fortran/trans-types.c
+++ b/gcc/fortran/trans-types.c
@@ -2435,7 +2435,7 @@ gfc_get_ppc_type (gfc_component* c)
   else
     t = void_type_node;
 
-  return build_pointer_type (build_function_type_list (t, NULL_TREE));
+  return build_pointer_type (build_function_type (t, NULL_TREE));
 }
 
 
Right now this is just a “call of comment”, let me know what you think about it. I will test the patch, both on x86_64-apple-darwin, then on aarch64-apple-darwin, to make sure it fixes stuff and doesn’t break anything else. But I can already confirm that it fixes my current testcases for this specific issue!

Cheers,
FX


PS: in order to perform checking, I am using the attached patch provided by Iain, which checks function calls during lowering in the middle-end.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: checking.diff
Type: application/octet-stream
Size: 2017 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20200906/c5516710/attachment.obj>


More information about the Fortran mailing list