[Patch, fortran] PR46328 - [OOP] type-bound operator call with non-trivial polymorphic operand

[Tobias Burnus]

Paul Richard Thomas wrote:
> This patch represents a rather complete fix for this PR.  In fact, I
> suspect that it also fixes other PRs but I have been out of internet
> range for a week and have not been able to check.

Truely awesome! I try to review the patch this year.

I can reproduce that PR 51334's attachment compiles and fails with
Operating system error: Cannot allocate memory
(which is expected, see c.l.f thread) - and the second version works. 
That's in line with the XLF and NAG result according to 
comp.lang.fortran :-)

I think your patch also fixes PR 51052 - at least the ICE is gone and 
after fixing the intent issue, the program compiles, runs and produces 
some output (no idea whether the output makes sense or not).

PR 46262: The small examples all compile without encountering an ICE; 
the big example (attachment) also compiles, but fails at run time with 
at segfault:
==6553== Invalid write of size 8
==6553==    at 0x4020C7: __lorenz_module_MOD_construct (lorenz.f03:35)
If one uncomments the line 34 (and changes % to _), the program runs and 
seems to produce the correct output. The problem is seemingly that 
realloc on assignment fails. (Cf. PR 48351.)


Unfortunately, the two other nested-operator bugs are not collaterally 
fixed; those are needed for Damian's examples.

* PR 51634: Now compiles, but fails at run time with a segfault:
==3657== Invalid write of size 4
==3657==    at 0x400ADF: __field_module_MOD_multiply (a.f90:26)
==3657==    by 0x400FA5: MAIN__ (a.f90:39)
Adding a
   f%f = [ 1, 2]
   g%f = [-1,-2]
and a final print *, g%f prints -3.5  -7. with PGI 11.5-0 thus the 
example should be valid.

* PR 46328 still shows the error:
Error: Operands of binary numeric operator '*' at (1) are 
CLASS(field)/REAL(4)
I wonder whether Janus' patchlets (cf. PR) would help together with your 
patch.


> Finally, the patch includes two extra bits: one brings back the
> nullification of newly assigned class array _data. (Tobias, is there a
> PR for this?);

PR 51529? At least it seems to be fixed by your patch. (Valgrind shows 
that the program leaks 304 bytes. It might be PR 46321 [polymorphic 
deallocate] but it could be also due to other issues.)

Tobias