This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
- From: Janus Weil <janus at gcc dot gnu dot org>
- To: Tobias Burnus <burnus at net-b dot de>
- Cc: gcc patches <gcc-patches at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Sat, 27 Jul 2013 12:04:53 +0200
- Subject: Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE => CLASS
- References: <51F1A31F dot 3040404 at net-b dot de> <CAKwh3qhS45WkQKMSJp9=QjJ1fhVU4VQK5LG0v-0Vf-r+QMWupg at mail dot gmail dot com> <51F39827 dot 8020607 at net-b dot de>
Hi,
>>> OK for the trunk?
>>
>> yes, the patch looks basically ok to me. Just one thing I did not
>> quite understand:
>>
>> + /* It can happen that the LHS has BT_DERIVED but it is in reality
>> + a polymorphic variable. */
>>
>> How exactly can it happen that a polymorphic variable is BT_DERIVED?
>
> I don't know. I commented it and it still works with the new test cases - it
> failed with one of them before. Probably some other change in this patch
> fixed the issue. As I cannot reproduce it anymore - and as I didn't like it
> either, I will remove it.
To me that sounds like a bug - if the symbol is BT_CLASS, then the
expr should be BT_CLASS (unless there is further decoration). By
chance I also just noticed one such case when debugging PR 57285.
If you happen to find out when this occurs or where the problem
originates from, that would be very helpful.
> OK for the trunk without that bit?
Yes, ok.
Thanks for the patch,
Janus