[Bug middle-end/102630] New: [12 Regression] Spurious -Warray-bounds with named address space

[Bug middle-end/102630] New: [12 Regression] Spurious -Warray-bounds with named address space

[jsm28 at gcc dot gnu.org]

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

            Bug ID: 102630
           Summary: [12 Regression] Spurious -Warray-bounds with named
                    address space
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: rejects-valid
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jsm28 at gcc dot gnu.org
                CC: msebor at gcc dot gnu.org
  Target Milestone: ---
            Target: x86_64-*-*

Created attachment 51560
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51560&action=edit
preprocessed source

This is the issue breaking building glibc for x86_64 with current mainline GCC
(since July), as previously discussed in threads starting at
https://gcc.gnu.org/pipermail/gcc/2021-July/236922.html and
https://gcc.gnu.org/pipermail/gcc/2021-July/236933.html (discussion continues
into August).

Compile the attached file with -O2 -Wall -Werror and get the errors:

loadmsgcat.c: In function '_nl_load_domain':
loadmsgcat.c:770:22: error: array subscript 0 is outside array bounds of
'__seg_fs struct pthread * __seg_fs[0]' [-Werror=array-bounds]

As discussed in the previous discussions, the code generating this
-Warray-bounds warning needs to check targetm.addr_space.zero_address_valid to
determine whether zero or small constant addresses are valid in the given
address space (there's already a suitable definition of that hook for x86, but
the warning is failing to check it).

[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> 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 <msebor at gcc dot gnu.org> ---
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

[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com <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

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
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

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> 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

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
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 ()
{
  <bb 2> [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 ()
{
  <bb 2> [local count: 1073741824]:
  MEM[(<address-space-1> char *)0B] = 0;
  MEM[(<address-space-1> char *)1B] = 1;
  return;

}

[Bug middle-end/102630] [12 Regression] Spurious -Warray-bounds with named address space

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
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

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Martin Sebor <msebor@gcc.gnu.org>:

https://gcc.gnu.org/g:54fa5567a27eb7ee72cd2321d0291c8a9b436ce9

commit r12-4376-g54fa5567a27eb7ee72cd2321d0291c8a9b436ce9
Author: Martin Sebor <msebor@redhat.com>
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

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> ---
Fixed in r12-4376.