The was_finalized tracking mechanism was introduced in commit 1af22e4 to
prevent duplicate finalization of the same expression+component combination
within a namespace. However, this mechanism had a flaw: it
stored gfc_expr* pointers that could become stale, leading to use-after-free
bugs and compi
On 6/18/25 2:02 PM, Mikael Morin wrote:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Was there a PR for this? or something you just ran into?
Not a problem either way, just curious.
It looks OK to me. OK for master.
Jerry
-- >8 --
gcc/fortran/ChangeL
Am 17.06.25 um 21:27 schrieb Harald Anlauf:
Am 17.06.25 um 19:44 schrieb Steve Kargl:
On Tue, Jun 17, 2025 at 12:05:34PM +0300, Janne Blomqvist wrote:
On Mon, Jun 16, 2025 at 9:41 PM Harald Anlauf wrote:
Am 16.06.25 um 02:18 schrieb Steve Kargl:
Harald,
I did a quick glance at the patch an
Hi Mikael,
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Just wondering... how does this relate to the recent fix of PR120483
by Andre? Is this also a regression? If so, maybe a backport would be
in order.
Best regads
Thomas
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_deferred_array): Statically
initialize deferred length variable for SAVEd character arrays.
gcc/testsuite/ChangeLog:
* gfortran.d
