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 33FAF3858D32; Tue, 25 Apr 2023 19:02:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 33FAF3858D32
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1682449366;
	bh=QSwZCT5Ka1/FeGBPLSUiXWn0ol5C6g6++l7/mDOHJVU=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=va+mrdrwR8UB9lTKRCR1Wk5w8TRL4c8j0PCxe2x/j05JizIigcWeosgq1VUqh0ye6
	 4dSrOXMvO+rL3qtSqGxWoLx0j7NCF7r8fVXQv74ukpx4fp5u5uF0UeHqaEYNmoo6OJ
	 ZtpPIfB7YzSu360CKd0deR2D1kwz/WK5RIajzvi4=
From: "gjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/105523] Wrong warning array subscript [0] is outside
 array bounds
Date: Tue, 25 Apr 2023 19:02:45 +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: 12.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gjl at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: saaadhu at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-105523-4-TUdY3NKpCK@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-105523-4@http.gcc.gnu.org/bugzilla/>
References: <bug-105523-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=3D105523

--- Comment #29 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
(In reply to David Brown from comment #20)
> This is not an AVR backend issue - it is much wider than that.  It is
> perhaps reasonable to test a patch just on the AVR, but this needs to be
> fixed in the core of gcc.

Ok, just the fact that the issue is sitting there for > 1 year now lead me =
to
the conclusion it's an AVR issue...

On older AVR devices, SFR area starts at 0x20, but on newer devices it star=
ts
at 0x0.  There are devices where 0x0 is actually some SFR address like PINB=
 for
ATtiny10 just to mention one.

At least for AVR, the warning does not make sense for dereferencing volatile
pointers to addresses known at compile time.

But there are also cases for addresses known only at link time, like with A=
VR
attribute __address__ or __io__.

Hence, for any addresses known at link time or earlier (aka. immediates), t=
he
warning makes no sense to me, because you cannot allocate them, anyways. (A=
nd
when you can allocate by means of, say, a memory protection unit, GCC is ou=
t of
the game.)=