Hi Andre,
Am 16.12.24 um 15:26 schrieb Andre Vehreschild:
Hi Harald,
thanks for finding the bug so quickly. I took another look and came up with the
attached trivially looking patch, which replaces the old version 1 entirely.
The new v2 version of the patch just makes use of existing code guessing the
type of the associate variable, which once I found it worked surprisingly
well. I have also extended the testcase.
this patch is really obvious and does work, too!
Regtests ok on x86_64-pc-linux-gnu. Ok for mainline?
Clearly OK for mainline. And since it is so simple, also for
backporting if you are inclined to do so. (14 is certainly fine).
Thanks for the patch!
Harald
Regards,
Andre
On Fri, 13 Dec 2024 14:09:25 +0100
Harald Anlauf <anl...@gmx.de> wrote:
Hi Andre,
while the patch works with the reduced testcase, it runs into the
newly added gcc_assert() when trying the original testcase in the PR.
I also wonder if this use of gcc_assert() is a good idea or good style:
+ gcc_assert (gfc_resolve_expr (tgt_expr));
Since gcc_assert is a macro, and its precise definition depends on
configuration and could possibly be defined to be a no-op, I suggest
to evaluate arguments with side-effects outside and pass the
return code to gcc_assert. (There are also many other ways to handle
this situation.
Then removing the gcc_assert around the gfc_resolve_expr() avoids
the ICE, but restores the reported error.
So not OK yet. Sorry!
Thanks,
Harald
Am 13.12.24 um 10:10 schrieb Andre Vehreschild:
Hi all,
attached patch fixes an reject-valid of an array constructor in an
associate by resolving the array constructor before parsing the
associate-block. I am not 100% sure, if that is the right place to do this.
But given, that there is already a special casing before the patch, I just
propose to do the resolve there.
Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline ?
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
--
Andre Vehreschild * Email: vehre ad gmx dot de
