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 2F5863858C51; Tue, 22 Mar 2022 00:25:20 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F5863858C51
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/104970] [12 Regression] ICE in execute_todo,
 at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b
Date: Tue, 22 Mar 2022 00:25:19 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: msebor at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: siddhesh at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-104970-4-u8AqzOxGD9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-104970-4@http.gcc.gnu.org/bugzilla/>
References: <bug-104970-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
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2022 00:25:20 -0000

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

--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> ---
The dollar sign in the internal attr_access string implies a VLA bound and =
the
attr_access::vla_bounds() function queries the VLA bounds.  That should mak=
e it
possible to distinguish the two cases.

Unlike the top-level VLA [N] notation which (unfortunately) implies no size
constraint on the actual argument, attribute access is meant to imply that =
the
array must have at least N elements (i.e., it's equivalent to [static N]).

As an aside, the tests cases in r12-6480 exercise only a small subset of
possible use cases: BDOS mode 0 results for calls to a function with attrib=
ute
access with either a dynamic size (known and unknown result) and a constant
size equal to array size.  There are many more use cases that aren't being
tested  that should be (e.g., larger or smaller arrays of constant size than
the size argument indicates with BDOS modes other than 0).=