Le 07/11/2021 à 00:56, Bernhard Reutner-Fischer a écrit :
On Sat, 6 Nov 2021 13:04:07 +0100
Mikael Morin <morin-mik...@orange.fr> wrote:
Le 05/11/2021 à 23:08, Bernhard Reutner-Fischer a écrit :
On Fri, 5 Nov 2021 19:46:16 +0100
Mikael Morin <morin-mik...@orange.fr> wrote:
I’m a bit concerned by the loss of the null_expr’s type interface.
I can’t convince myself that it’s either absolutely necessary or
completely useless.
It's a delicate spot, yes, but i do think they are completely useless.
If we do NOT need a finalization, the initializer can (and has to be
AFAIU) be a null_expr and AFAICS then does not need an interface.
Well, the null pointer itself doesn’t need a type, but I think it’s
better if the pointer it’s assigned to has a type different from void*.
It will (hopefully) help the middle-end optimizers downstream.
I would not expect this to help all that much or at all TBH.
So i compiled
for i in $(grep -li final $(grep -L dg-error
/scratch/src/gcc-12.mine/gcc/testsuite/gfortran.dg/*.f*)); do gfortran -O2
-fcoarray=single -c $i -g -g3 -ggdb3 -fdump-tree-original
-fdump-tree-optimized;done
and diffed all .original and .optimized dumps against pristine trunk
and they are identical.
I inspected and ran the binary from finalize_14 and there is no change
in the leaks compared to pristine trunk. The 3 shape_w in p leak as
they used to. I do remember that finalize_14 was a good testcase, in
sum i glared at it for quite some time ;)
In fact, the interface is not used.
the type is built in gfc_get_ppc_type which has the following.
/* Explicit interface. */
if (c->attr.if_source != IFSRC_UNKNOWN && c->ts.interface)
return build_pointer_type (gfc_get_function_type (c->ts.interface));
As components have no if_source attribute set, the type is not built
here and a default function type is built further down without interface
information.
This is probably unintended as the components’ initializers carefully
set an if_source attribute.
The problem has been identified before ; see vaguely related posts from
FX in september 2020.
Anyway, I don’t think your changes will have negative impact then, and
it makes things more readable, so I’m fine with it after all; OK.
I will see if I can manage to create a testcase where it makes a
difference (don’t hold your breath, I don’t even have a bootstrapped
compiler ready yet).
That'd be great, TIA!
[]
I’ve given up eventually.
btw.. Just because it's vagely related.
I think f8add009ce300f24b75e9c2e2cc5dd944a020c28 for
PR fortran/88009 (ICE in find_intrinsic_vtab, at fortran/class.c:2761)
is incomplete in that i think all the internal class helpers should be
flagged artificial. All these symbols built in gfc_build_class_symbol,
generate_finalization_wrapper, gfc_find_derived_vtab etc.
Looking at the history it seems the artificial bit often was forgotten.
I guess so, yes...
And most importantly i think it is not correct to ignore artificial in
gfc_check_conflict!
Well, it’s not correct to throw errors at users for things they haven’t
written and that they don’t control.
