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 347B7385828B; Mon, 27 Nov 2023 08:15:07 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 347B7385828B
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1701072907;
	bh=BRhkugFHaaeYxUbc9I91swuHPLZadHzeR4UsbnPqWNA=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=pafNG6W4Iv1Xb664tPnUw+gvxJxFcuc4EE/ATKl8W2CIzXw/JF12U87jh7Y1IF2D/
	 jgICxfsGMOtSBiqv7k/4oN47becQd9BAYY/Tsp5YZjJ43j/YTS/y4yMrCH96E9XO6V
	 uVJ0R1Wl0Q7WzdVfRUA1nKqXERXB1eOuzUVskrcs=
From: "rdapp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/112598] RISC-V regression testsuite errors with
 rv64gcv_zvl512b
Date: Mon, 27 Nov 2023 08:15:06 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: testsuite-fail
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rdapp 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: 
Message-ID: <bug-112598-4-CmqONNMIF8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-112598-4@http.gcc.gnu.org/bugzilla/>
References: <bug-112598-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=3D112598

--- Comment #11 from Robin Dapp <rdapp at gcc dot gnu.org> ---
On Friday I looked into one of the Fortran fails, class_67.f90 and debugged=
 it
independently without reading here further.  It is also due to the same rea=
son
- alias analysis finds that the predicated store destination cannot alias w=
ith
the load destination and moves the load in front of the store.

  /* If the pointer based access is bigger than the variable they cannot
     alias.  This is similar to the check below where we use TBAA to
     increase the size of the pointer based access based on the dynamic
     type of a containing object we can infer from it.  */
  poly_int64 dsize2;
  if (known_size_p (size1)
      && poly_int_tree_p (DECL_SIZE (base2), &dsize2)
      && known_lt (dsize2, size1))
    return false;

This is where alias analysis "fails".  That looks like the exact same thing
posted in the other thread, so thanks for finding that, Pan.=