From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A89123858D3C; Tue, 25 Apr 2023 19:07:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A89123858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1682449668; bh=YsmDChQZ8UC2DeglrgbhlAVzNbWvnO0yM7hUXcEyaYo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=O4u01DainDVEkdM4SDLPVF6F4AU1+8Iks05wLRZYyH9GxrGDIJx5Q+efH1gNQ3M/P 0RrxW7DDsw/Xaqm4gqKYRye8XsnJ+NJR/+F/bWHR1B53DJ9jRTmyYLJtPMf2DKshq7 AkWps2TsHYB7Z1iNqiRuFGQP69ybev5OaoWiJu7E= From: "konrad at silmor dot de" 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:07:48 +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: konrad at silmor dot de 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D105523 --- Comment #30 from Konrad Rosenbaum --- (In reply to Andrew Pinski from comment #28) > (In reply to Wilhelm M from comment #26) > > As you can see in my opening bug report, there is no nullptr reference = nor > > dereferencing a pointer with value 0. >=20 > Yes but as I mentioned by the time the warning happens, the IR has lost > information if the constant came from a null pointer or from some other > constant that the user used. So a heuristic needs to be used and the idea > was it would be the lower bytes by default and that the lower bytes would= be > defined by a "page size" and that is how the naming of the option happene= d. To be honest, this sounds like a missing feature or even a design bug: shouldn't the IR be aware of what original address (type) a pointer/array originated from? If it makes a difference whether I access a[70] or a[700000000] then the heuristic is not very helpful. If a useful option has a completely unintuit= ive name that is also a problem. Null pointers usually derive from nullptr, NULL or the integer constant 0. I think it would be worth a flag or two to mark code pathes that transmit real null pointers or offsets to real null pointers. Anything derived from a non-zero integer is something that the programmer bears full responsibility= for - if he wants to aim at his foot, let him! Even if something derives from integer 0 (as opposed to nullptr or NULL), t= here is a chance that it was something that is intended (on the MCU I'm currently using this is the register that sets the first 8 GPIO pins) - usually "volatile" will be a good indicator of that, because memory mapped registers are always volatile. A few examples I can think of: struct MyStruct { int a,b,c; }; auto *nps =3D (MyStruct*)nullptr; // -> originates from a nullptr, definite= ly a problem! auto *npi =3D &nps->c; // -> still derived from nullptr, still a problem! MyStruct myvar; auto *vps =3D &myvar ; // -> dereferences a real variable, definitely not a problem auto *vpi =3D &vps->c; // -> still not a problem auto *sps =3D (MyStruct*)0x101; // -> static address, very likely not a pro= blem or at least the programmer's problem, not the compiler's auto *spi =3D &sps->c; // same here auto *xps =3D (MyStruct*)0x00; // -> static address, but 0x00 -> probably n= ullptr auto *xpi =3D &xps->c; // -> derived from probably nullptr -> probably a pr= oblem struct VMyStruct { volatile int a,b,c; }; auto *yps =3D (VMyStruct*)0x00; // -> static null address, but has volatile members, may or may not be problematic auto *ypi =3D &yps->c; // -> derived from static null address, but access is volatile, it's the programmer's problem, no warning auto *zps =3D (VMyStruct*)NULL; // NULL=3D((void*)0) -> derived from non-vo= latile pointer to 0, count it like nullptr! No heuristic at the point of use will be able to properly catch and categor= ize those. There will have to be some flags that get passed along with the (changing) pointer value. Even then there should be a way to tell the compiler whether (SomeType*)0 i= s a null pointer or a pointer to a legitimate memory location. Can pointer valu= es have attributes? The question that remains is: is this change worth it and might it help to catch other problems?=