[Bug c/100680] New: false positive warning for certain __builtin_memcmp() argument

[Bug c/100680] New: false positive warning for certain __builtin_memcmp() argument

[jbeulich at suse dot com]

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

            Bug ID: 100680
           Summary: false positive warning for certain __builtin_memcmp()
                    argument
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jbeulich at suse dot com
  Target Milestone: ---

In this example

struct s {
        char a[8];
        int i;
        long l;
};

extern char ea[8];
static char sa[8] = { 1, 2, 3, 4 };

int test(void) {
        const struct s*ps = (const struct s *)0x12345678L;

        if(__builtin_memcmp(ps->a, ps->a, 8))
                return 0;

        if(__builtin_memcmp(ps->a, ea, 8))
                return 0;

        if(__builtin_memcmp(ps->a, sa, 8))
                return 0;

        if(__builtin_memcmp(ps->a, "abcdABCD", 8))
                return 0;

        return 1;
}

all except, oddly enough, the first invocation cause "'__builtin_memcmp'
specified bound of 8 exceeds source size of 0 [-Wstringop-overread]". Obviously
the above example is heavily simplified from actual uses in the Xen hypervisor
sources, but clearly in (at least) OS and alike low-level development it is not
uncommon for pointers to get derived from known integer constants.

[Bug c/100680] false positive warning for certain __builtin_memcmp() argument

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I believe this is wrong "fallback" for failing to extract a size from the
pointer constant argument.  It should be unknown, not zero.

Martin?

[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning is by design: it considers a constant non-null pointer value a
likely result of (invalid) arithmetic on a null pointer, as in the example in
pr99578 comment #1.

*** This bug has been marked as a duplicate of bug 99578 ***

[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument

[jbeulich at suse dot com]

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

--- Comment #3 from jbeulich at suse dot com ---
(In reply to Martin Sebor from comment #2)
> The warning is by design: it considers a constant non-null pointer value a
> likely result of (invalid) arithmetic on a null pointer, as in the example
> in pr99578 comment #1.

If the warning is by design, there ought to be a way to avoid these specific
instances without disabling the warning altogether. I'm also observing such
bogus warnings in cases other than pointer derivation from literal numbers,
possibly along the lines of what Andi has said in that other bug in comment 12.
For Xen I've submitted a patch to work around the issue without disabling the
warning, but it's not really pretty:

https://lists.xen.org/archives/html/xen-devel/2021-05/msg01058.html

I also consider Richard's comment 7 in that other bug as quite relevant. The
compiler _guessing_ that offsetting from a NULL pointer is an actual issue
conflicts with people intentionally doing so. Warnings based on heuristics
should imo always be separately controllable, such that they can - if the
heuristics prove to be wrong - be turned off, without affecting other,
non-heuristic warnings. This is even more relevant for all those projects (like
the Xen hypervisor) building with -Werror, resulting in false positive warnings
breaking the build.

[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:32ca611c42658948f1b8883994796f35e8b4e74d

commit r12-7713-g32ca611c42658948f1b8883994796f35e8b4e74d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 18 18:58:06 2022 +0100

    Allow (void *) 0xdeadbeef accesses without warnings [PR99578]

    Starting with GCC11 we keep emitting false positive -Warray-bounds or
    -Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
    style accesses (or memory/string routines to such pointers).
    This is a standard programming style supported by all C/C++ compilers
    I've ever tried, used mostly in kernel or DSP programming, but sometimes
    also together with mmap MAP_FIXED when certain things, often I/O registers
    but could be anything else too are known to be present at fixed
    addresses.

    Such INTEGER_CST addresses can appear in code either because a user
    used it like that (in which case it is fine) or because somebody used
    pointer arithmetics (including &((struct whatever *)NULL)->field) on
    a NULL pointer.  The middle-end warning code wrongly assumes that the
    latter case is what is very likely, while the former is unlikely and
    users should change their code.

    The following patch adds a min-pagesize param defaulting to 4KB,
    and treats INTEGER_CST addresses smaller than that as assumed results
    of pointer arithmetics from NULL while addresses equal or larger than
    that as expected user constant addresses.  For GCC 13 we can
    represent results from pointer arithmetics on NULL using
    &MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs.

    2022-03-18  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99578
            PR middle-end/100680
            PR tree-optimization/100834
            * params.opt (--param=min-pagesize=): New parameter.
            * pointer-query.cc
            (compute_objsize_r) <case ARRAY_REF>: Formatting fix.
            (compute_objsize_r) <case INTEGER_CST>: Use maximum object size
instead
            of zero for pointer constants equal or larger than min-pagesize.

            * gcc.dg/tree-ssa/pr99578-1.c: New test.
            * gcc.dg/pr99578-1.c: New test.
            * gcc.dg/pr99578-2.c: New test.
            * gcc.dg/pr99578-3.c: New test.
            * gcc.dg/pr100680.c: New test.
            * gcc.dg/pr100834.c: New test.

[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18

commit r11-9731-g91f7d7e1bb6827bf8e0b7ba7eb949953a5b1bd18
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 18 18:58:06 2022 +0100

    Allow (void *) 0xdeadbeef accesses without warnings [PR99578]

    Starting with GCC11 we keep emitting false positive -Warray-bounds or
    -Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
    style accesses (or memory/string routines to such pointers).
    This is a standard programming style supported by all C/C++ compilers
    I've ever tried, used mostly in kernel or DSP programming, but sometimes
    also together with mmap MAP_FIXED when certain things, often I/O registers
    but could be anything else too are known to be present at fixed
    addresses.

    Such INTEGER_CST addresses can appear in code either because a user
    used it like that (in which case it is fine) or because somebody used
    pointer arithmetics (including &((struct whatever *)NULL)->field) on
    a NULL pointer.  The middle-end warning code wrongly assumes that the
    latter case is what is very likely, while the former is unlikely and
    users should change their code.

    The following patch adds a min-pagesize param defaulting to 4KB,
    and treats INTEGER_CST addresses smaller than that as assumed results
    of pointer arithmetics from NULL while addresses equal or larger than
    that as expected user constant addresses.  For GCC 13 we can
    represent results from pointer arithmetics on NULL using
    &MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs.

    2022-03-18  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99578
            PR middle-end/100680
            PR tree-optimization/100834
            * params.opt (--param=min-pagesize=): New parameter.
            * builtins.c (compute_objsize_r) <case INTEGER_CST>: Use maximum
            object size instead of zero for pointer constants equal or larger
            than min-pagesize.

            * gcc.dg/tree-ssa/pr99578-1.c: New test.
            * gcc.dg/pr99578-1.c: New test.
            * gcc.dg/pr99578-2.c: New test.
            * gcc.dg/pr99578-3.c: New test.
            * gcc.dg/pr100680.c: New test.
            * gcc.dg/pr100834.c: New test.

    (cherry picked from commit 32ca611c42658948f1b8883994796f35e8b4e74d)