* [Patch, fortran] PR104555 - ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095
@ 2023-10-29 12:29 Paul Richard Thomas
2023-10-29 19:15 ` Harald Anlauf
0 siblings, 1 reply; 2+ messages in thread
From: Paul Richard Thomas @ 2023-10-29 12:29 UTC (permalink / raw)
To: fortran, gcc-patches
[-- Attachment #1.1: Type: text/plain, Size: 905 bytes --]
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 <pault@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.
[-- Attachment #2: pr104555.f90 --]
[-- Type: text/x-fortran, Size: 752 bytes --]
! { dg-do compile }
!
! Test the fix for PR104555 in which the select type statement caused an
! ICE because the selector expression was type(t) rather than class(t).
!
! Contributed by Gerhard Steinmetz <gscfq@t-online.de>
!
program p
type t
character(:), allocatable :: a
end type
call s(t("abcd"))
call s([t("efgh")])
contains
subroutine s(x)
class(t) :: x(..)
select rank (x)
rank (0)
print *, "|", x%a, "|"
select type (y => x)
type is (t)
print *, "|", y%a, "|"
end select
rank (1)
print *, "|", x(1)%a, "|"
select type (y => x)
type is (t)
print *, "|", y(1)%a, "|"
end select
end select
end
end
[-- Attachment #3: submit.diff --]
[-- Type: text/x-patch, Size: 813 bytes --]
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 9f4dc072645..b394f7fc79c 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -9578,6 +9578,12 @@ resolve_select_type (gfc_code *code, gfc_namespace *old_ns)
{
if (code->expr1->symtree->n.sym->attr.untyped)
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. */
+ if (code->expr2->ts.type == BT_DERIVED
+ && code->expr2->symtree
+ && code->expr2->symtree->n.sym->ts.type == BT_CLASS)
+ code->expr2->ts = code->expr2->symtree->n.sym->ts;
selector_type = CLASS_DATA (code->expr2)
? CLASS_DATA (code->expr2)->ts.u.derived : code->expr2->ts.u.derived;
}
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Patch, fortran] PR104555 - ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095
2023-10-29 12:29 [Patch, fortran] PR104555 - ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095 Paul Richard Thomas
@ 2023-10-29 19:15 ` Harald Anlauf
0 siblings, 0 replies; 2+ messages in thread
From: Harald Anlauf @ 2023-10-29 19:15 UTC (permalink / raw)
To: Paul Richard Thomas, fortran, gcc-patches
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 <pault@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.
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-10-29 19:15 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-29 12:29 [Patch, fortran] PR104555 - ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095 Paul Richard Thomas
2023-10-29 19:15 ` Harald Anlauf
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).