This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 5 Aug 2013 11:16:28 +0200
- Subject: Re: [Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization
- References: <CAKwh3qgAJL9GRRDWfKp5MAx38DW=08P_CX2gV+JGEMVxkbj_fA at mail dot gmail dot com> <51F3977B dot 7060606 at net-b dot de> <CAKwh3qiHNtuqsgfqRkVbvxBvMs-YH47LT1sg05d4RuTA0Yr9Yw at mail dot gmail dot com> <CAKwh3qhqymsTc0krXMTJeLpZ92+rDAODWHU9z=PtEJfWpimw=g at mail dot gmail dot com> <CAKwh3qjAXCP0tfmv-JM5BSWH9thrRyVFfPzORTNN-CMr-eyHLg at mail dot gmail dot com> <CAKwh3qh9KiNY6BF99m_cy=x=MQZrN_X0p+1idJ=rKSfB=1rhaw at mail dot gmail dot com> <CAKwh3qgfbTBT+TppVJ6QHBecFRTHqUBmmXwP61ZnciEfP-QZdw at mail dot gmail dot com> <51FEC3F7 dot 4020000 at net-b dot de> <CAKwh3qj1zL3qTC_Si6myhLjCnawPv6wLYZShrhzCvfyiYmWVaA at mail dot gmail dot com>
>> Looking at gfc_class_initializer, I have the impression that it does not
>> handle initialization of unlimited polymorphic variables/components. I don't
>> know whether initialization is permitted, but my feeling is that the
>> following should work:
>>
>> type t
>> class(*), pointer :: x
>> end type t
>> type(t), target :: y
>> integer,target :: z
>> type(t) :: x = t(y)
>> type(t) :: x = t(z)
>> class(*), pointer :: a => y
>>
>> And I have the feeling that it is not correctly treated - but I might be
>> wrong. (Note to the example above: I believe "t(y)" is a valid structure
>> constructor, which is not yet supported. But again, I might be wrong about
>> either.)
>
> Your example yields (with and without the current patch):
>
> tobias2.f90:7.17:
>
> type(t) :: x = t(y)
> 1
> Error: Can't convert TYPE(t) to CLASS(*) at (1)
> tobias2.f90:8.17:
>
> type(t) :: x = t(z)
> 1
> Error: Can't convert INTEGER(4) to CLASS(*) at (1)
In fact this problem is more similar to PR 49213 than the one under
discussion here. I have added the above test case to PR 49213 as
comment 12.
Cheers,
Janus