[Bug fortran/96495] New: [gfortran] MERGE does not copy ALLOCATABLE property of derived type

[Bug fortran/96495] New: [gfortran] MERGE does not copy ALLOCATABLE property of derived type

[paul.luckner@rwth-aachen.de]

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

            Bug ID: 96495
           Summary: [gfortran] MERGE does not copy ALLOCATABLE property of
                    derived type
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: paul.luckner@rwth-aachen.de
  Target Milestone: ---

Created attachment 49011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49011&action=edit
proof of concept code

There is a bug in gfortran and I singled out the problem this far:

- a derived type with ALLOCATABLE data 
- a MERGE call
- an operator overloading used as argument to the MERGE call
- ELEMENTAL procedure

it is best to look at the proof of concept codes attached.
There are 4 highlighted code sections which should all yield similar results
but only one works whereas the others are broken.

The bug arises when called using a vector (using the ELEMENTAL feature).

====================
Supplementary information
$ gfortran --version
GNU Fortran (GCC) 10.1.0

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/exports/gcc-10.1.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-10.1.0-source/gcc-10.1.0/configure
--enable-languages=c,c++,fortran --enable-checking=release
--disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=gold --prefix=/usr/local/gcc-10.1.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC) 

$ cat /etc/os-release 
NAME="openSUSE Leap"
VERSION="15.1"

[Bug fortran/96495] [gfortran] MERGE does not copy ALLOCATABLE property of derived type

[paul.luckner@rwth-aachen.de]

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

paul.luckner@rwth-aachen.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #49011|0                           |1
        is obsolete|                            |

--- Comment #1 from paul.luckner@rwth-aachen.de ---
Created attachment 49042
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49042&action=edit
proof of concept code -- version 2

I investigated further and the bug arises under the following circumstances:
- derived type with ALLOCATABLE property
- a binary ELEMENTAL operator
- an unary operator

The following code will crash

f(1:2) = f(1:2) .binary. (.unary. f(1))

and the error message is as follows:
"Program received signal SIGSEGV: Segmentation fault - invalid memory
reference."

[Bug fortran/96495] [gfortran] MERGE does not copy ALLOCATABLE property of derived type

[paul.luckner@rwth-aachen.de]

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

paul.luckner@rwth-aachen.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #49042|0                           |1
        is obsolete|                            |

--- Comment #2 from paul.luckner@rwth-aachen.de ---
Created attachment 49044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49044&action=edit
proof of concept code -- version 3

The bug is not specific to binary/unary operators 
BUT RATHER 
the combination of an elemental operator where one argument is an array and the
other argument a scalar result of another operator.

The current code example (poc version 3) shows the bug using 

<array> = <array> .<binary elemental operator>. (.<unary operator>. <scalar>)
OR
<array> = <array> .<binary elemental operator>. (<scalar> .<binary operator>.
<scalar>)

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pault at gcc dot gnu.org
                 CC|                            |pault at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-08-28

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Paul,

Thank you very much for this report. The cause if the segfault is revealed by
using the option -fdump-tree-original.

The assignment
  g = g .binaryElemental. (f .binary. f)

is rendered as:

    {
      struct foo D.4200;

      D.4200 = foo_sub_foo (&f, &f);  /* Outside the scalarization loop.  */
      {                               /* ...as it should be :-)   */
        integer(kind=8) S.30;

        S.30 = 1;
        while (1)
          {
            if (S.30 > 2) goto L.21;
            {
              struct foo * D.4202;
              struct foo D.4203;

              D.4202 = &D.4200;
              D.4203 = g[S.30 + -1];
              g[S.30 + -1] = foo_add_foo (&g[S.30 + -1], D.4202);
              if ((integer(kind=4)[0:] * restrict) D.4203.j.data != 0B)
                {
                  __builtin_free ((void *) D.4203.j.data);
                  (integer(kind=4)[0:] * restrict) D.4203.j.data = 0B;
                }

              /* Here the 'j' component of the scalar temporary is
                 deallocated on the first pass through the scalarization
                 loop so that the second pass through the loop attempts
                 to read a null address.  /*
              if ((integer(kind=4)[0:] * restrict) D.4202->j.data != 0B)
                {
                  __builtin_free ((void *) D.4202->j.data);
                  (integer(kind=4)[0:] * restrict) D.4202->j.data = 0B;
                }
            }
            S.30 = S.30 + 1;
          }
        L.21:;
      }
    }

As you can see from the comments, the garbage collection mechanism is overdoing
it and the deallocation of D.4202->j should be done outside the scalarization
loop.

I presume that you have already found the workaround:
  tmp = (f .binary. f)
  g = g .binaryElemental. tmp

where tmp is a scalar of type 'foo'?

This does the right thing...
    {
      struct foo D.4201;

      D.4201 = tmp;
      tmp = foo_sub_foo (&f, &f);
      if ((integer(kind=4)[0:] * restrict) D.4201.j.data != 0B)
        {
          __builtin_free ((void *) D.4201.j.data);
          (integer(kind=4)[0:] * restrict) D.4201.j.data = 0B;
        }
    }
    {
      struct foo * D.4202;

      D.4202 = &tmp;
      {
        integer(kind=8) S.30;

        S.30 = 1;
        while (1)
          {
            if (S.30 > 2) goto L.21;
            {
              struct foo D.4204;

              D.4204 = g[S.30 + -1];
              g[S.30 + -1] = foo_add_foo (&g[S.30 + -1], D.4202);
              if ((integer(kind=4)[0:] * restrict) D.4204.j.data != 0B)
                {
                  __builtin_free ((void *) D.4204.j.data);
                  (integer(kind=4)[0:] * restrict) D.4204.j.data = 0B;
                }
            }
            S.30 = S.30 + 1;
          }
        L.21:;
      }
    }
  }
}

I will work on this in the coming days.

Best regards

Paul

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
The fix is submitted at:
https://gcc.gnu.org/pipermail/fortran/2020-August/054945.html

Regards

Paul

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:e86a02f87d8a11480c1421ef2dd71b8b5f43d938

commit r11-3430-ge86a02f87d8a11480c1421ef2dd71b8b5f43d938
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Thu Sep 24 11:52:30 2020 +0100

    This patch fixes PR96495 - frees result components outside loop.

    2020-24-09  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/96495
            * trans-expr.c (gfc_conv_procedure_call): Take the deallocation
            of allocatable result components of a scalar result outside the
            scalarization loop. Find and use the stored result.

    gcc/testsuite/
            PR fortran/96495
            * gfortran.dg/alloc_comp_result_2.f90 : New test.

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:5b26b3b3f5c75a86a5a3e851866247ac7fcb6c8b

commit r11-3480-g5b26b3b3f5c75a86a5a3e851866247ac7fcb6c8b
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Sat Sep 26 12:32:35 2020 +0100

    Correct overwrite of alloc_comp_result_2.f90 in fix of PR96495.

    2020-26-09  Paul Thomas  <pault@gcc.gnu.org>

    gcc/testsuite/
            PR fortran/96495
            * gfortran.dg/alloc_comp_result_2.f90 : Restore original.
            * gfortran.dg/alloc_comp_result_3.f90 : New test.

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #7 from Paul Thomas <pault at gcc dot gnu.org> ---
Since this is not a regression, I am closing.

Thanks for the report

Paul

[Bug fortran/96495] [gfortran] Composition of user-defined operators does not copy ALLOCATABLE property of derived type

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |here.is.a.gcc.bug at gmail dot com

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
*** Bug 99549 has been marked as a duplicate of this bug. ***