From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 98052387102E; Mon, 20 Nov 2023 14:07:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 98052387102E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1700489242;
	bh=QIUwZ5RPlZvRpkFIqTzHGOEbnh7d95/Xgu+uxpGMKzY=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=dwIozddKQrWJEHaxwphICxx5+GgFlcCk4crV1yoTmidhLrOEt374XhXGhYU5HlC6p
	 OilxhZYo1+PkFicd6iS/djdza3t3dPrbuFBURqrKVEeIduQvBBa7CFigkdhc6W83rs
	 fhwCzLc0pozR5qAYUNcyfKceK0Zla8Uf1NVQ8e4Q=
From: "burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/110415] (Re)allocation on assignment to allocatable
 polymorphic variable from allocatable polymorphic function result
Date: Mon, 20 Nov 2023 14:07:19 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 13.1.1
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: burnus at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-110415-4-1ZUs0HyKvR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110415-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110415-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Andrew Jenner's submitted patch (gcc-patches@ only):
  https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636671.html
and (fortran@ only):
  https://gcc.gnu.org/pipermail/fortran/2023-November/059928.html
(Replies should got to both lists ...)

* * *

Technical it is a regression caused by
 https://gcc.gnu.org/r13-6747-gd7caf313525a46f200d7f5db1ba893f853774aee
but before that commit there was no finalization.

Comparing the versions:
  GCC 7+8: ICE in build_function_decl
  GCC 10+11+12: memory leak in 'func'
  GCC 13+mainline: segfault at runtime  (at 'a =3D func()' in the main prog=
ram).

* * *

I had analyzed the issue the elsewhere, let's copy it here for completeness=
 and
possibly to aid the patch review. (Note: The following was written before t=
he
patch was written and analyzed the current status.)

---<cut-----

The 'func' has the prototype 'struct __class_MAIN___P_a func ()', i.e. retu=
rns
the class-wrapper directly - and that part looks okay.

However, the assignment somehow mixes everything up:

    D.4349 =3D a->_vptr;  // save old value of vptr
    D.4328 =3D func ();   // new value

    desc.0.data =3D (void * restrict) D.4328._data;
// As scalar, there is not really a problem, but an
//    desc.0.dtype.elem_len =3D D.4328->_vptr->size;
// is missing here.
    desc.0.span =3D (integer(kind=3D8)) desc.0.dtype.elem_len;

    if (__builtin_expect ((integer(kind=3D8)) (a->_data =3D=3D 0B), 0, 42))
        a->_data =3D (struct p *) __builtin_malloc (MAX_EXPR <(unsigned lon=
g)
a->_vptr->_size, 1>);
  // WRONG: That should use D.4328->_vptr->size!

    else
      {
        if (a->_vptr !=3D D.4349)
          {
            __builtin_realloc ((void *) a->_data, a->_vptr->_size);

Likewise: a->_vptr should be D.4328->_vptr.

Alternatively, a->_vptr had to be updated before the 'if' block.=