[Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size

[Bug fortran/67430] New: reallocate lhs with overloaded assignment operators causes memory error and wrong size

[alipasha.celeris at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430

            Bug ID: 67430
           Summary: reallocate lhs with overloaded assignment operators
                    causes memory error and wrong size
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alipasha.celeris at gmail dot com
  Target Milestone: ---

Created attachment 36284
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36284&action=edit
the test file with line numbers matching the Valgrind output.

The following code produces a memory error in Valgrind (an invalid read) and
does not reallocate the LHS to the correct size.  

      MODULE A_TEST_M
        TYPE :: A_TYPE
          INTEGER :: INT
!
          CONTAINS
!
          GENERIC :: ASSIGNMENT (=) => ASGN_A
          PROCEDURE, PRIVATE :: ASGN_A
        END TYPE

        CONTAINS

        ELEMENTAL SUBROUTINE ASGN_A (A, B)
          CLASS (A_TYPE), INTENT (INOUT) :: A
          CLASS (A_TYPE), INTENT (IN) :: B
!
          A%INT = 45
        END SUBROUTINE
      END MODULE A_TEST_M

      PROGRAM ASGN_REALLOC_TEST
        USE A_TEST_M
        TYPE (A_TYPE), ALLOCATABLE :: A(:)
!
        ALLOCATE (A(4))
        A(1:2)%INT = 7
        A(3:4)%INT = 13
!
        A = A(1:2)
!
        PRINT *, 'SIZE(A)', SIZE(A), 'A:', A
      END PROGRAM

The results look like this (valgrind output):

==30070== Memcheck, a memory error detector
==30070== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==30070== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright
info
==30070== Command: ./a.out
==30070== 
==30070== Invalid read of size 8
==30070==    at 0x402F148: _intel_fast_memcpy (vg_replace_strmem.c:946)
==30070==    by 0x400CA1: MAIN__ (asgn_realloc_test.f:29)
==30070==    by 0x400DF3: main (asgn_realloc_test.f:22)
==30070==  Address 0x50f37c8 is 0 bytes after a block of size 8 alloc'd
==30070==    at 0x402BB20: malloc (vg_replace_malloc.c:299)
==30070==    by 0x400C13: MAIN__ (asgn_realloc_test.f:29)
==30070==    by 0x400DF3: main (asgn_realloc_test.f:22)
==30070== 
 SIZE(A)           4 A:          45          45           0           0

"A" should have size of 2 after assignment (being reallocated).  It seems that
the overloaded operator is being used (it is rigged to assign 45).  

The intrinsic assignment (when = is not overloaded) works fine.

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The code in comment 0 is invalid: in

A = A(1:2)

you assign two elements to a four element array. If you compile your code with
'-fcheck=all', you get at run time the error

At line 29 of file pr67430.f90
Fortran runtime error: Array bound mismatch for dimension 1 of array 'a' (2/4)

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

[andrew at boldfriend dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430

--- Comment #2 from Andrew Baldwin <andrew at boldfriend dot org> ---
In 7.2.1.4 of my copy of the standard it states:

"A subroutine defines the defined assignment x1 = x2 if"

...

"(5) either
    (a) the ranks of x1 and x2 match those of d1 and d2 or
    (b) the subroutine is elemental, x1 and x2 are conformable, and there is no
other subroutine that defines the assignment."

Since x1 and x2 are not conformable in this instance the defined assignment
(overloaded assignment) my reading is that it should not occur.

However, assigning two elements to an allocatable array allocated to four
elements is not invalid for intrinsic assignment.  Note 7.38 in my copy of the
standard states:

"If C is an allocatable array of rank 1, then

C = PACK(ARRAY,ARRAY>0)

will cause C to contain all the positive elements of ARRAY in array element
order; if C is not allocated or is allocated with the wrong size, it will be
re-allocated to be of the correct size to hold the result of PACK."

This behavior is observed when the overloaded assignment operator is not
provided.  The output in that case is:

 SIZE(A)           2 A:           7           7

It is also observed when the defined assignment does not meet the requirement
(5a).  I.e. replacing the defined assignment with

        SUBROUTINE ASGN_A (A, B)
          CLASS (A_TYPE), INTENT (OUT) :: A(:)
          CLASS (A_TYPE), INTENT (IN) :: B
!
          A(:)%INT = 45
        END SUBROUTINE

and changing the generic binding to a generic interface.  The output in that
case is also:

 SIZE(A)           2 A:           7           7

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

[anlauf at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #3 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Andrew Baldwin from comment #2)
> In 7.2.1.4 of my copy of the standard it states:
> 
> "A subroutine defines the defined assignment x1 = x2 if"
> 
> ...
> 
> "(5) either
>     (a) the ranks of x1 and x2 match those of d1 and d2 or
>     (b) the subroutine is elemental, x1 and x2 are conformable, and there is
> no other subroutine that defines the assignment."

It also says:

"If d1 or d2 is an array, the shapes of x1 and x2 shall match the shapes of d1
and d2 , respectively."

This is not the case for your example.

(NAG and Crayftn also do not reallocation.)

> Since x1 and x2 are not conformable in this instance the defined assignment
> (overloaded assignment) my reading is that it should not occur.

I'm no standard expert, but (5)(a) appears to be satisfied, so the
non-conformance of x1 and x2 does not matter.

To be sure, consider posting your question on comp.lang.fortran.

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Am I correct to summarize (simplify?) your expectation (interpretation as:

use the overloaded assignment if the lhs and rhs are conforming, otherwise use
the intrinsic assignment?

If yes, what the compiler should do if some bounds are only known at run time?

I agree with the first comment of Ian Harvey at
https://groups.google.com/forum/#!topic/comp.lang.fortran/Vk4D8iDZOdc.

I have no opinion for the second test in the above thread, beside a "don't do
that!". If you think it is a gfortran bug, please file a new PR and, if
possible, outputs from other compilers you have access to.

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |SUSPENDED
   Last reconfirmed|                            |2015-09-05
         Resolution|INVALID                     |---
     Ever confirmed|0                           |1

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
>From https://groups.google.com/forum/#!topic/comp.lang.fortran/Vk4D8iDZOdc

This has just been discussed on the J3 mailing list.  (Bob Corbett (I 
think) picked up the original question and passed it on).  My 
understanding of the discussion so far is that 
A)  whoops, there's an error introduced by the reallocation on 
assignment stuff 
B)  It has always been the intent of J3 to make the distinction between 
defined and intrinsic assignment to be a compile time choice. 
C)  A (likely? possible?) fix is to add something like "unless the ranks 
are different" to one of the rules in the disambiguation text for 
intrinsic and defined assignment.  (It's possible it was "ranks are the 
same", I don't remember) 

That's about all I remember of the discussion. 

Dick Hendrickson 

Marking this PR as SUSPENDED while waiting for the J3 ruling.

[Bug fortran/67430] reallocate lhs with overloaded assignment operators causes memory error and wrong size

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67430

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #5)

> Marking this PR as SUSPENDED while waiting for the J3 ruling.

Do you know how the discussion turned out?