This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign
- From: Tobias Burnus <burnus at net-b dot de>
- To: Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>
- Cc: Mikael Morin <mikael dot morin at sfr dot fr>, gcc-patches <gcc-patches at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Sun, 16 Sep 2012 19:36:03 +0200
- Subject: Re: [Patch, fortran] PR46897 - [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign
- References: <CAGkQGiLUJSqmV-CdnbiK=iVMsfgP62a3X28kDsCsXUDjPTNa3A@mail.gmail.com> <50294461.2070704@sfr.fr> <CAGkQGiL9Y9b1JCYSE7ftv5J=WOfF80MTMhH3CaSrgKShD4JSjg@mail.gmail.com> <502A0F81.7060106@sfr.fr> <CAGkQGi+wqPFad_oZBOv3fCZFpr17rbA1B_kU5AC-d9NXwc3KOg@mail.gmail.com> <CAGkQGiKUfxLdbGaC0Xa=xs9BZiybvJBBvyjnEPLnoqrjyZUTyw@mail.gmail.com>
Am 10.09.2012 20:58, schrieb Paul Richard Thomas:
Bootstrapped and regtested on FC9/x86_64 - OK for trunk?
The following test case doesn't work; it should print "Overloaded" - and
does so with crayftn. But with your patch, it doesn't.
Tobias
module a_mod
type :: a
contains
procedure :: a_ass
generic :: assignment(=) => a_ass
end type a
type c
type(a) :: ta
end type c
type :: b
type(c) :: tc
end type b
contains
impure elemental subroutine a_ass(out, in)
class(a), intent(out) :: out
type(a), intent(in) :: in
print *, "Overloaded"
end subroutine a_ass
end module a_mod
program assign
use a_mod
type(b) :: tt
type(b) :: tb1
tt = tb1
end program assign
+ build_assignment (gfc_exec_op op, gfc_expr *expr1, gfc_expr *expr2, +
gfc_component *comp1, gfc_component *comp2, locus loc)
For comp1/comp2, I am wondering whether one shouldn't add a
gcc_assert ((comp1 && comp2) || (!comp1 && !comp2));
+ get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
Not that we make so much use of it, but its symbol could be a candidate
for attr.artificial. (I don't know whether it should.)