Hi all, pushed as gcc-15-6292-g9684e70952a. Thanks for the review.
- Andre On Mon, 16 Dec 2024 19:15:12 +0100 Harald Anlauf <anl...@gmx.de> wrote: > 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 > -- Andre Vehreschild * Email: vehre ad gmx dot de
