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: Andre Vehreschild <vehre at gmx dot de>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- 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:16:47 +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> <CAGkQGi+L5AZC9RMnN3XoNuxV9CsQEEKqrB_SE9TkDDUZxY3CAg@mail.gmail.com>
Hi Paul,
> 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 think that I figured the rule:
- when no _class-ref is present, then the type is BT_CLASS,
- as soon as a _class-ref is present the type is BT_DERIVED.
There is an attr.is_class. Would that be an alternative? I don't know how
reliable it is set.
> > 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 :-(
I found an error in my patch that only manifests itself with an optimization
level great than 0. Now I am searching, never having done anything there.
- Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de