Hi Paul,
code->expr1->symtree->n.sym->ts = code->expr2->ts;
+ /* Sometimes the selector expression is given the typespec of the
+ '_data' field, which is logical enough but inappropraite here. */
s/inappropraite/inappropriate/
+ if (code->expr2->ts.type == BT_DERIVED
otherwise it LGTM.
Thanks for the patch!
Harald
On 10/29/23 13:29, Paul Richard Thomas wrote:
Bizarrely, since the fix for pr101625, the testcase compiles and runs
correctly with s/select type (y => x)/select type (y => (x))/ !
The fix is straightforward and appears to be one of those wrinkles arising
from the use of associate variables as a selector. The fault is reasonable
since the expression is a reference to the _data field, which is of derived
type. However, being a select type selector, the selector must be a
class with that declared type.
Regtests fine. OK for mainline?
Paul
Fortran: Fix a problem with SELECT TYPE selectors [PR104555].
2023-10-29 Paul Thomas <pa...@gcc.gnu.org>
gcc/fortran
PR fortran/104555
* resolve.cc (resolve_select_type): If the selector expression
has no class component references and the expression is a
derived type, copy the typespec of the symbol to that of the
expression.
gcc/testsuite/
PR fortran/104555
* gfortran.dg/pr104555.f90: New test.
