[Patch, fortran] PR83118 - [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

[Paul Richard Thomas]

Hi All,

Sunil reported failures of unlimited_polymorphic_32.f03 with -m32. The
attached patch fixes these failures through the chunks in trans-array.c and
the new function. It turned out that the vptr being used was that of the
unlimited polymorphic object, rather than the dynamic type. It was an
unfortunate coincidence that the testcase worked with -m64.

In the course of investigating this problem, I found two kinds of memory
leak in the execution of the testcase. The first is due to the allocatable
components in the result for new_wrapper not being freed and is fixed by
the chunk in gfc_trans_assignment_1. The second is due to the allocatable
components of the unlimited polymorphic lhs, 'obj'. This will be the
subject of a later fix.

Regtests on FC33/x86_64 and the testcase is fixed with -m32. OK for master?

Paul

Fix failures with -m32 and some memory leaks.

2020-12-23  Paul Thomas  <pault@gcc.gnu.org>

gcc/fortran
PR fortran/83118
* trans-array.c (gfc_alloc_allocatable_for_assignment): Make
sure that class expressions are captured for dummy arguments by
use of gfc_get_class_from_gfc_expr otherwise the wrong vptr is
used.
* trans-expr.c (gfc_get_class_from_gfc_expr): New function.
(gfc_get_class_from_expr): If a constant expression is
encountered, return NULL_TREE;
(gfc_trans_assignment_1): Deallocate rhs allocatable components
after passing derived type function results to class lhs.
* trans.h : Add prototype for gfc_get_class_from_gfc_expr.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repair1.diff
Type: text/x-patch
Size: 4064 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20201223/22665146/attachment.bin>