Sorry, I hadn’t seen your message.
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:
Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit :
On Wed, 27 Oct 2021 23:39:43 +0200
Bernhard Reutner-Fischer <rep.dot....@gmail.com> wrote:
On Mon, 15 Oct 2018 10:23:06 +0200
Bernhard Reutner-Fischer <rep.dot....@gmail.com> wrote:
If a finalization is not required we created a namespace containing
formal arguments for an internal interface definition but never used
any of these. So the whole sub_ns namespace was not wired up to the
program and consequently was never freed. The fix is to simply not
generate any finalization wrappers if we know that it will be unused.
Note that this reverts back to the original r190869
(8a96d64282ac534cb597f446f02ac5d0b13249cc) handling for this case
by reverting this specific part of r194075
(f1ee56b4be7cc3892e6ccc75d73033c129098e87) for PR fortran/37336.
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 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).
Don’t you get the same effect on the memory leaks if you keep just the
following hunk?
No, i don't think emitting the finalization-wrappers unconditionally is
correct.
> (... lengthy explaination ...)
>
Agreed, it was a poor suggestion.
The rest of the changes (appart from class.c) are mostly OK with the nit
below and should be put in their own commit.
>>> @@ -3826,10 +3828,8 @@ free_tb_tree (gfc_symtree *t)
>>>
>>> free_tb_tree (t->left);
>>> free_tb_tree (t->right);
>>> -
>>> - /* TODO: Free type-bound procedure structs themselves; probably
needs some
>>> - sort of ref-counting mechanism. */
>>> free (t->n.tb);
Please keep a comment; it remains somehow valid but could be updated
maybe: gfc_typebound_proc’s u.generic field for example is nowhere freed
as far as I know.
Well that's a valid point, not sure where they are freed indeed.
Do you have a specific testcase in mind that leaks tbp's u.generic (or
specific for that matter) for me to look at?
Any testcase with generic typebound procedures, I guess.
typebound_generic_3.f03 for example seems like a good candidate.
I'm happy to change the comment to
TODO: Free type-bound procedure u.generic and u.specific fields
to reflect the current state. Ok?
I don’t think specific leaks because it’s one of gfc_namespace’s
sym_root sub-nodes, and it’s freed with gfc_namespace.
OK without "and u.specific".
