Hi Paul,
Am 29.12.21 um 12:45 schrieb Paul Richard Thomas via Fortran:
Hi Harald,
That is the sort of thing that I had in mind. Is it worth adding the check
for CLASS_DATA? I cannot remember if that is made redundant by the test of
the class_ok attribute.
the macro CLASS_DATA appears to have been introduced by Janus
as a shortcut to the data component. Accesses to the data
component still may require a protecting prior check when we
are confronted with random bad user code, as I sometimes see
sym->attr.class_ok == 1 but still sym->ts.u.derived == NULL.
Shall we open a PR for tracking issues with (the lack of)
canonical checking when CLASS is involved? Where we could
collect ideas about macros that make the code more readable
and robust? (I believe some PRs involving "associate" need
similar treatment in several places.)
Of course that would be something for post 12-release.
Cheers,
Harald
Cheers
Paul
On Tue, 28 Dec 2021 at 21:08, Harald Anlauf <anl...@gmx.de> wrote:
Hi Paul,
Am 28.12.21 um 12:56 schrieb Paul Richard Thomas via Fortran:
Hi Harald,
This looks good to me. OK for mainline and, dare I suggest, 11-branch?
From a quick run through resolve.c, there are many places where the
extra
checks that you introduced in the patch have been implemented. This makes
me wonder whether a function or macro might not make the relevant code
more
concise.
I had thought about this in the past, too. Suitably chosen macros
could help to make checking not only more concise, but also more
robust and (hopefully) readable at the same time.
What do you think about e.g.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index e5d2dd7971e..f3d22b46a75 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3885,6 +3885,8 @@ bool gfc_is_finalizable (gfc_symbol *, gfc_expr **);
&& CLASS_DATA (sym) \
&& CLASS_DATA (sym)->attr.dimension \
&& !CLASS_DATA (sym)->attr.class_pointer)
+#define IS_CLASS_OBJ(sym) \
+ (sym->ts.type == BT_CLASS && sym->attr.class_ok)
/* frontend-passes.c */
to be used to ensure that we are dealing with a CLASS object where
attributes should already have been set up? Or use a better name?
(IS_CLASS_OBJECT?)
Thanks,
Harald
Thanks for the patch
Paul
On Mon, 27 Dec 2021 at 22:17, Harald Anlauf via Fortran <
fort...@gcc.gnu.org>
wrote:
Dear all,
there are a couple of NULL pointer dereferences leading to improper
error recovery when trying to handle Gerhard's testcases involving
SELECT TYPE and invalid uses of CLASS variables.
The fixes look pretty obvious to me, but I'm submitting here to
check if there is more that should be done here.
(I was surprised to see that there are several different places
involved by rather simple variations in the basic test case.)
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
