https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88688
Bug ID: 88688
Summary: Incorrect association in SELECT TYPE
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: thfanning at gmail dot com
Target Milestone: ---
Created attachment 45334
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45334&action=edit
Test case demonstrating issue.
SELECT TYPE constructs may not correctly associate the local name with the
polymorphic selector. For example, consider the following snippet:
call tp%setref(i)
select type (ap => tp%ptr)
class default
call tp%setref(j)
lp => ap
call set7(lp)
end select
where 'setref' associates the pointer component 'ptr' to the actual argument.
In this case, should the name 'lp' associate with the original value of the
selector 'tp%ptr' (which is associated with 'i'), or with the updated value of
tp%ptr (which is newly associated with 'j')?
When compiled with fortran 8.2, the attached program produces the following:
$ gfortran debug2.f90
$ ./a.out
I: 3
J: 7
When compiled with Intel Fortran, the attached program produces the following:
$ ifort debug2.f90
$ ./a.out
I: 7
J: 4
It's not clear what the correct behavior should be. Does 'ap' associate with
the pointer or the pointee? In other words, is 'ap' just a syntactic
simplification, or does it "bind" with the polymorphic entity at the point of
definition? It should be the latter, which means there is a bug in gfortran.
