This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran, OOP] PR 56266: ICE on invalid in gfc_match_varspec
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: Mikael Morin <mikael dot morin at sfr dot fr>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 13 Apr 2013 16:02:33 +0200
- Subject: Re: [Patch, Fortran, OOP] PR 56266: ICE on invalid in gfc_match_varspec
- References: <CAKwh3qhJCDe7o-JqBLMj_ejT+nJrUQi3UVxPdPxiGCxURnmOgw at mail dot gmail dot com> <51695BFC dot 9010101 at sfr dot fr>
>> Unless someone has a better idea how to treat this, I will commit the
>> attached patch as obvious.
> Not really a better idea, but it seems to me that function calls can
> have trailing sub-references, so that gfc_match_varspec could be called
> on them.
> gfc_match_rvalue has:
> switch (sym->attr.flavor)
> case FL_UNKNOWN:
> [... try to match a variable ...]
> /* Give up, assume we have a function. */
> e->expr_type = EXPR_FUNCTION;
> gfc_match_actual_arglist (...);
> /* If our new function returns a character, array or structure
> type, it might have subsequent references. */
> m = gfc_match_varspec (e, ...);
> So, it seems that EXPR_FUNCTION is acceptable in gfc_match_varspec.
> And then, there is nothing preventing 'c(i)' in 'c(i)%encM()' from being
> parsed as a function. Is this supported?
I think this is forbidden by the Fortran standard, cf. e.g.
Actually I'm not sure in which context a function call with sub-refs
would be valid. One should re-check the standard on this ...
(Btw, I have already committed the patch as r197936.)