[Bug middle-end/96987] New: [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[Bug middle-end/96987] New: [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[ibuclaw at gdcproject dot org]

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

            Bug ID: 96987
           Summary: [11 regression] warning 'ptr' may be used
                    uninitialized const pointer parameter
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Possibly related to pr96564.  Remove 'const' from the prototype, and there is
no warning.

---
extern void constparam(const int *ptr);

int main()
{
    int* ptr = (int*)__builtin_malloc(sizeof(int) * 8);
    if (ptr != 0)
        constparam(ptr);
    return 0;
}

[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
   Target Milestone|---                         |11.0

[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
When ignoring that constparam could cast the constness away from the pointer or
that the function wouldn't ever touch the pointer, how could it ever
dereference the pointer and have it not uninitialized?

[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |msebor at gcc dot gnu.org
         Resolution|---                         |INVALID

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning is by design and based on the assumption that a function declared
to take a const pointer (or in C++, a const reference) as an argument reads the
pointed-to-object.  If that's not the case annotating the function declaration
with attribute as shgwn below suppresses the warning:

  extern __attribute__ ((access (none, 1))) void constparam(const int *ptr);

[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[ibuclaw at gdcproject dot org]

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

--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
And what about other front-ends that do not have the luxury of C attributes?

Looking at the original library code of where the warning was noticed, the
function being called (GC.addRange) definitely doesn't read the pointer, but
records the address and allocation size for scanning later.

[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[ibuclaw at gdcproject dot org]

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

--- Comment #4 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
And what about void pointers?  How is it assumed that the pointed to object is
read when it has no value?

Expanded example loosely rewritten from the original library code.
---
void GC_addRange(const void * const, __SIZE_TYPE__);

struct VoidArray
{
  __SIZE_TYPE__ length;
  void *ptr;
};

// struct Array(T) {
#define T int
bool isInitialized;
VoidArray _data;
__SIZE_TYPE__ _capacity;

void
reserve (__SIZE_TYPE__ elements)
{
  if (!isInitialized)
    {
      if (!elements) return;
      __SIZE_TYPE__ sz;
      int overflow = __builtin_mul_overflow (elements, sizeof (T), &sz);
      if (overflow) __builtin_abort ();
      void *p = __builtin_malloc (sz);
      if (!p) __builtin_abort ();
      // static if (hasIndirections!T) {
        GC_addRange (p, sz);
      // }
      _data.ptr = p;
      _data.length = 0;
      _capacity = elements;
    }
  else
    {
      // _data.reserve (elements);
    }
}

// };

[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
A void pointer is usually cast to one to a complete type that's then used to
access the object (e.g., bsearch).  But not every instance of every warning
should be expected to indicate a bug.  Most only suggest that there might be
one.  The documented purpose of GCC warnings is to "report constructions that
are not inherently erroneous but that are risky or suggest there may have been
an error."  This rare use is one such case.  It was considered when the warning
was designed and deemed an acceptable trade-off.  (The attribute was added to
help accommodate  it.)

If adding support for attribute access to the D front end isn't feasible to
mark up the function and avoid the warning that way, I would suggest removing
the const qualifier from the pointer (following the practice of the C++
standard garbage collector APIs) or providing an non-const overload. 
Alternatively, writing into a byte of the allocated memory will prevent the
warning as well.

[Bug middle-end/96987] [11 regression] warning 'ptr' may be used uninitialized const pointer parameter

[ibuclaw at gdcproject dot org]

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

--- Comment #6 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to Martin Sebor from comment #5)
> A void pointer is usually cast to one to a complete type that's then used to
> access the object (e.g., bsearch).  But not every instance of every warning
> should be expected to indicate a bug.  Most only suggest that there might be
> one.  The documented purpose of GCC warnings is to "report constructions
> that are not inherently erroneous but that are risky or suggest there may
> have been an error."  This rare use is one such case.  It was considered
> when the warning was designed and deemed an acceptable trade-off.  (The
> attribute was added to help accommodate  it.)
> 
> If adding support for attribute access to the D front end isn't feasible to
> mark up the function and avoid the warning that way, I would suggest
> removing the const qualifier from the pointer (following the practice of the
> C++ standard garbage collector APIs) or providing an non-const overload. 
> Alternatively, writing into a byte of the allocated memory will prevent the
> warning as well.

Changing the API is not really an option as that sits in upstream.

Thinking more about it.  Though it isn't immediately intuitive, one implication
of the warning could be that the GC may run a mark/sweep between the time
GC.addRange is called and the allocated data being initialized, thus leading to
the possibility of false pointers being seen during the scan.

So I'll relax my stance on this, however was certainly thrown off by the way
the warning presented itself as shown in pr96989.