Hi Paul,
thanks for that tremendous patch!
Reviewing it properly is beyond me, but if nobody else volunteers,
I'll just provide a few minor comments derived from playing with it,
and let you decide to push or polish.
In testcase class_transformational_2.f90 I recommend to "harden"
the select type () blocks in check_result and check_result_a by e.g.
class default
stop stop_flag + 4
so that wrong dynamic types are detected (I had fun with ifx... :).
There are also unused declared variables (e.g. ss(:)), probably left
overs.
I got an ICE compiling class_transformational_1.f90 with the following
options:
% gfc-15 class_transformational_1.f90 -O3 -fcheck=bounds
Note that -O3 and -fcheck=bounds seem essential. I get:
f951: internal compiler error: in make_ssa_name_fn, at tree-ssanames.cc:355
0x26ab458 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0x99dc1c fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1696
0x8947a8 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
../../gcc-trunk/gcc/tree-ssanames.cc:355
0x11e879b make_ssa_name(tree_node*, gimple*)
../../gcc-trunk/gcc/tree-ssanames.h:99
0x11e879b remap_ssa_name
../../gcc-trunk/gcc/tree-inline.cc:238
[...]
I did not try to narrow that down further. If you decide to push
the submitted patch, and if you can reproduce the above, then please
open a separate PR to track this. Given what the patch resolves,
this is not a real show-stopper, so you may go ahead.
Thanks,
Harald
Am 29.11.24 um 23:21 schrieb Paul Richard Thomas:
Hi Harald,
Sorry about that - it was the standard HEAD versus HEAD~ mistake.
Thanks for pointing it out.
Paul
On Fri, 29 Nov 2024 at 17:31, Harald Anlauf <anl...@gmx.de> wrote:
Hi Paul,
the patch seems to contain stuff that has already been pushed
(gcc/testsuite/gfortran.dg/pr117768.f90, and the chunks in
class.cc and resolve.cc). Can you please check?
Cheers,
Harald
Am 29.11.24 um 17:34 schrieb Paul Richard Thomas:
Hi All,
This patch was originally pushed as r15-2739. Subsequently memory faults
were found and so the patch was reverted. At the time, I could find where
the problem lay. This morning I had another look and found it almost
immediately :-)
The fix is the 'gfc_resize_class_size_with_len' in the chunk '@@ -1595,14
+1629,51 @@ gfc_trans_create_temp_array '. Without it,, half as much
memory
as needed was being provided by the allocation and so accesses were
occurring outside the allocated space. Valgrind now reports no errors.
Regression tests with flying colours - OK for mainline?
Paul
