This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, fortran] PR69566 - Failure of SELECT TYPE with unlimited polymorphic function result
- From: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- To: Andre Vehreschild <vehre at gmx dot de>
- Cc: "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 18 Oct 2016 18:12:38 +0200
- Subject: Re: [Patch, fortran] PR69566 - Failure of SELECT TYPE with unlimited polymorphic function result
- Authentication-results: sourceware.org; auth=none
- References: <CAGkQGiKZ4mH5auK_U3bK7EG_oL9BSd7wCY=FW2SuSGo1efuZXg@mail.gmail.com> <20161018172436.39c1bf58@vepi2>
Hi Andre,
Thanks for a quick response:
> You can use
>
> || (e->symtree && UNLIMITED_POLY (e->symtree->n.sym));
Ah yes, you are quite right.
> here. UNLIMITED_POLY does all the checks. I am still wondering whether this is
> necessary? The symtree is set for expr_type == { EXPR_VARIABLE, EXPR_FUNCTION }
> both of those should correctly resolve to an unlimited poly ts. Is this a
> left-over?
For reasons I don't understand, sometimes the expression type comes
through as BT_DERIVED, whilst the symbol is BT_CLASS. I could repair
this in resolve.c(fixup_array_ref) if you think that would be cleaner.
>
> I am regression testing my polymorhpic class patch at the moment, therefore I
> can't test.
OK - I can wait. I have quite a few other things to do :-(
Cheers
Paul
--
The difference between genius and stupidity is; genius has its limits.
Albert Einstein