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 E71173858D20; Thu,  2 May 2024 13:07:49 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E71173858D20
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1714655269;
	bh=0888Vn+26IhKpYHo5PLPxInWbulr24OjnUMFdV6/64M=;
	h=From:To:Subject:Date:From;
	b=wLhrp0hjmuHcyv8LbFw83S+4+KtUOWiLcao+cqXE1vhmixGMPnqny/gj3/CEANBjR
	 dQ4U6alRuS9AcRd1WUmEbpM+AsC1PbRHXtDGXQRzthA+EozmX9Iu96W9tqQgpCGxiA
	 o0gDcm5fHmFgd2hFMalgU3E0STqLUhAgUhk4IEa0=
From: "acoplan at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/114924] New: [11/12/13/14/15 Regression] Wrong
 update of MEM_EXPR by RTL loop unrolling since r11-2963-gd6a05b494b4b71
Date: Thu, 02 May 2024 13:07:49 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: acoplan at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-114924-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=3D114924

            Bug ID: 114924
           Summary: [11/12/13/14/15 Regression] Wrong update of MEM_EXPR
                    by RTL loop unrolling since r11-2963-gd6a05b494b4b71
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

The following testcase is reduced from
libgomp/testsuite/libgomp.fortran/imperfect-destructor.f90:

module m
  type t
    contains
      final fini
  end type
  integer ccount(3)
  contains
    subroutine init(x, n)
      type(t) x
      xi =3D n
      ccount =3D 1
    end
    subroutine fini(x)
      type(t) x
      dcount=3D s1 (a3)
  do i =3D 1, 1
    block
      do j =3D 1, 2
        block
          do k =3D 1, a3
            block
              type (t) local3
              call init (local3, 3)
            end block
          end do
        end block
      end do
    end block
  end do
end
end

compiling with -O2 -funroll-loops -da and looking at the RTL dumps, I see t=
he
following insn in 284r.loop2_invariant:

(insn 44 40 45 8 (set (mem/c:SI (plus:DI (reg/f:DI 121)
                (const_int 8 [0x8])) [3 ccount[2]+0 S4 A64])
        (subreg:SI (reg:V2SI 111) 0)) "t.f90":11:16 discrim 2 69
{*movsi_aarch64}
     (expr_list:REG_DEAD (reg:V2SI 111)
        (nil)))

then in 285r.loop2_unroll, I see:

(insn 44 40 45 8 (set (mem/c:SI (plus:DI (reg/f:DI 121)
                (const_int 8 [0x8])) [3 ccount+0 S4 A64])
        (subreg:SI (reg:V2SI 111) 0)) "t.f90":11:16 discrim 2 69
{*movsi_aarch64}
     (expr_list:REG_DEAD (reg/f:DI 121)
        (expr_list:REG_DEAD (reg:V2SI 111)
            (nil))))

notably the MEM_EXPR has been changed from ccount[2] to ccount, without a
corresponding change in offset.  This is incorrect.  Setting a watchpoint on
the
MEM_ATTRS of the relevant MEM showed that the update happens in
cfgrtl.cc:duplicate_insn_chain, which does the following:

        /* We cannot adjust MR_DEPENDENCE_CLIQUE in-place
           since MEM_EXPR is shared so make a copy and
           walk to the subtree again.  */
        tree new_expr =3D unshare_expr (MEM_EXPR (*iter));
        if (TREE_CODE (new_expr) =3D=3D WITH_SIZE_EXPR)
          new_expr =3D TREE_OPERAND (new_expr, 0);
        while (handled_component_p (new_expr))
          new_expr =3D TREE_OPERAND (new_expr, 0);
        MR_DEPENDENCE_CLIQUE (new_expr) =3D newc;
        set_mem_expr (const_cast <rtx> (*iter), new_expr);

so the code (correctly) looks through the ARRAY_REF in this case to find
the underlying MEM_REF and updates MR_DEPENDENCE_CLIQUE for that
MEM_REF, but then proceeds to pass the MEM_REF to set_mem_expr, thereby
incorrectly dropping the ARRAY_REF in this case.

The code above was introduced in
r11-2963-gd6a05b494b4b714e996a5ca09c5a4a1c41dbd648 so I assume this is a
regression in GCC 11 and beyond.

I have a straightforward patch to fix this which passes bootstrap on
aarch64-linux-gnu, I will post that shortly.

While I don't have a wrong-code reproducer at the moment, we may want to
consider backporting the fix as incorrect MEM_EXPR information could
lead to wrong code.  I found the issue while working on a patch series
that has the side effect of introducing some consistency checking of the
MEM_EXPR information.=