[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Martin Sebor --- Fixed in r12-4376.
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:54fa5567a27eb7ee72cd2321d0291c8a9b436ce9 commit r12-4376-g54fa5567a27eb7ee72cd2321d0291c8a9b436ce9 Author: Martin Sebor Date: Wed Oct 13 10:31:37 2021 -0600 Check to see if null pointer is dereferenceable [PR102630]. Resolves: PR middle-end/102630 - Spurious -Warray-bounds with named address space gcc/ChangeLog: PR middle-end/102630 * pointer-query.cc (compute_objsize_r): Handle named address spaces. gcc/testsuite/ChangeLog: PR middle-end/102630 * gcc.target/i386/addr-space-2.c: Add -Wall. * gcc.target/i386/addr-space-3.c: New test.
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581243.html
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
--- Comment #5 from Martin Sebor ---
Section 25.8. Using FS and GS segments in user space applications in
https://www.kernel.org/doc/html/latest/x86/x86_64/fsgs.html makes it sound like
null might be a valid address in a named address space. I don't know if it
really is in Glibc (is it?). The patch below suppresses the warning in GCC.
diff --git a/gcc/pointer-query.cc b/gcc/pointer-query.cc
index 83b1f0fc866..910f452868e 100644
--- a/gcc/pointer-query.cc
+++ b/gcc/pointer-query.cc
@@ -41,6 +41,7 @@
#include "pointer-query.h"
#include "tree-pretty-print.h"
#include "tree-ssanames.h"
+#include "target.h"
static bool compute_objsize_r (tree, int, access_ref *, ssa_name_limit_t &,
pointer_query *);
@@ -1869,13 +1870,24 @@ compute_objsize_r (tree ptr, int ostype, access_ref
*pref,
if (code == INTEGER_CST)
{
/* Pointer constants other than null are most likely the result
-of erroneous null pointer addition/subtraction. Set size to
-zero. For null pointers, set size to the maximum for now
-since those may be the result of jump threading. */
+of erroneous null pointer addition/subtraction. Unless zero
+is a valid address set size to zero. For null pointers, set
+size to the maximum for now since those may be the result of
+jump threading. */
if (integer_zerop (ptr))
pref->set_max_size_range ();
+ else if (POINTER_TYPE_P (TREE_TYPE (ptr)))
+ {
+ tree deref_type = TREE_TYPE (TREE_TYPE (ptr));
+ addr_space_t as = TYPE_ADDR_SPACE (deref_type);
+ if (targetm.addr_space.zero_address_valid (as))
+ pref->set_max_size_range ();
+ else
+ pref->sizrng[0] = pref->sizrng[1] = 0;
+ }
else
pref->sizrng[0] = pref->sizrng[1] = 0;
+
pref->ref = ptr;
return true;
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630
--- Comment #4 from Martin Sebor ---
A test case is below. Warnings for accesses at address zero are intentionally
suppressed (to avoid false positives for unreachable code) but they are issued
for accesses at nonzero offsets from null because those are often the result of
invalid arithmetic on null pointers.
This bug is about the warning in g() where supposedly the null pointer may
represent a valid address.
$ cat pr102630.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout
pr102630.c
void f (void)
{
char *p = 0;
p[0] = 0;// no warning (intentional)
p[1] = 1;// -Warray-bounds (intentional)
}
void g (void)
{
char __seg_fs *p = 0;
p[0] = 0;// no warning (intentional)
p[1] = 1;// -Warray-bounds (intentional)
}
pr102630.c: In function ‘f’:
pr102630.c:5:4: warning: array subscript 0 is outside array bounds of ‘char[0]’
[-Warray-bounds]
5 | p[1] = 1;// -Warray-bounds (intentional)
| ~^~~
;; Function f (f, funcdef_no=0, decl_uid=1978, cgraph_uid=1, symbol_order=0)
(executed once)
void f ()
{
[local count: 1073741824]:
MEM[(char *)0B] ={v} 0;
__builtin_trap ();
}
pr102630.c: In function ‘g’:
pr102630.c:12:4: warning: array subscript 0 is outside array bounds of
‘__seg_fs __seg_fs char[0]’ [-Warray-bounds]
12 | p[1] = 1;// -Warray-bounds (intentional)
| ~^~~
;; Function g (g, funcdef_no=1, decl_uid=1982, cgraph_uid=2, symbol_order=1)
void g ()
{
[local count: 1073741824]:
MEM[( char *)0B] = 0;
MEM[( char *)1B] = 1;
return;
}
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630 --- Comment #3 from Martin Sebor --- If the warning is keeping Glibc from building with GCC 12 then applying the patch until this is resolved (hopefully still in stage 1, or in stage 3) seems like a reasonable workaround. It wouldn't be the first time it had to be done. I just haven't had to work on this yet.
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630 --- Comment #2 from joseph at codesourcery dot com --- Since we concluded this was a GCC bug, rather than an unavoidable limitation of the warning, suppressing it in glibc seems inappropriate.
[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102630 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Blocks||56456 Ever confirmed|0 |1 Keywords|rejects-valid |diagnostic Last reconfirmed||2021-10-06 --- Comment #1 from Martin Sebor --- Thanks for filing this. It's been on my list of things to look into but it helps to have a bug tracking it. For what it's worth, it hasn't been a priority for me since I posted a simple patch to suppress the Glibc warning (https://sourceware.org/pipermail/libc-alpha/2021-July/128829.html). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds
