https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96325
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
--- Comment #8 from kargl at gcc dot gnu.org ---
(In reply to Kirill Chilikin from comment #7)
> Result of git bisect:
>
(bisection removed)
> f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47 is the first bad commit
> commit f79be3a7dbf8d9cd7e675918472ebc3c2c9d5e47
> Author: Paul Thomas <pa...@gcc.gnu.org>
> Date: Mon Sep 2 19:54:02 2019 +0000
>
> re PR fortran/91589 (ICE in gfc_conv_component_ref, at
> fortran/trans-expr.c:2447)
>
> 2019-09-02 Paul Thomas <pa...@gcc.gnu.org>
>
> PR fortran/91589
> * primary.c (gfc_match_varspec): Return MATCH_NO on an apparent
> component ref, when the primary type is intrinsic.
>
> 2019-09-02 Paul Thomas <pa...@gcc.gnu.org>
>
> PR fortran/91589
> * gfortran.dg/pr91589.f90 : New test.
>
> From-SVN: r275324
Thank for the bisection. The system I'm sitting in front of is too
slow to attempt a bisection. I have developed a patch, which yields
% gfcx -c a.f90
a.f90:11:16:
11 | a = t%r1%foo(1) ! There is no foo component/TBP.
| 1
Error: 'foo' at (1) is not a component of the derived type 't2'
For the last testcase I posted. I have not regression tested the
patch, so have no ideas if there are unforeseen side-effects. I'll
just put the patch here for others to find.
Index: gcc/fortran/primary.c
===================================================================
--- gcc/fortran/primary.c (revision 280157)
+++ gcc/fortran/primary.c (working copy)
@@ -2240,6 +2240,16 @@ gfc_match_varspec (gfc_expr *primary, int equiv_flag,
inquiry = is_inquiry_ref (name, &tmp);
if (inquiry)
sym = NULL;
+ else
+ {
+ component = gfc_find_component (sym, name, false, false, &tmp);
+ if (!component)
+ {
+ gfc_error ("%qs at %C is not a component of the derived "
+ "type %qs", name, sym->name);
+ return MATCH_ERROR;
+ }
+ }
if (sep == '%' && primary->ts.type != BT_UNKNOWN)
intrinsic = true;
