[Bug c/102329] New: pointer "maybe uninitialized" right after assignment

[Bug c/102329] New: pointer "maybe uninitialized" right after assignment

[hv at crypt dot org]

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

            Bug ID: 102329
           Summary: pointer "maybe uninitialized" right after assignment
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: hv at crypt dot org
  Target Milestone: ---

Reduced from perl source code:

% cat test.c
extern void *malloc (long unsigned int size);
extern void f1 (const void *pointer);

void perl_alloc(void) {
    void *vp1 = malloc(1);
    /* *(char*)vp1 = 0; */
    f1((const void *)vp1);
}
% gcc-11.2.0 -c -Wmaybe-uninitialized -O2 test.c
test.c: In function 'perl_alloc':
test.c:7:5: warning: 'vp1' may be used uninitialized [-Wmaybe-uninitialized]
    8 |     f1((const void *)vp1);
      |     ^~~~~~~~~~~~~~~~~~~~~
test.c:2:13: note: by argument 1 of type 'const void *' to 'f1' declared here
    3 | extern void f1 (const void *pointer);
      |             ^~
% 

This build of gcc was configured as follows (including the error in prefix):
  ../gcc/configure --prefix=/opt/gcc-12 --disable-gcov --disable-multilib
--enable-languages=c --disable-nls --disable-decimal-float

No warning is seen under my system "gcc-9 (Ubuntu 9.2.1-17ubuntu1~18.04.1)
9.2.1 20191102", nor does 11.2.0 complain if the commented-out assignment is
uncommented, nor if 'malloc' is renamed to 'f2', nor if 'const' is removed from
the signature of f1 along with the corresponding cast.

Is the warning intended to imply that the memory pointed to by vp1 may be
uninitialized, rather than vp1 itself? If so, perhaps it is only that the
message is misleadingly worded, and making possibly inappropriate assumptions
about what f1() may do.

[Bug c/102329] pointer "maybe uninitialized" right after assignment

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This was added in r11-959-gb825a22890740f341eae566af27e18e528cd29a7

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[hv at crypt dot org]

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

--- Comment #2 from Hugo van der Sanden <hv at crypt dot org> ---
I guess this is justified by the second paragraph of the -Wmaybe-uninitialized
docs: "In addition, passing a pointer (or in C++, a reference) to an
uninitialized object to a const-qualified function argument is also diagnosed
by this warning."

Firstly, I'd request for this case that the wording of the diagnostic should
clarify that it's the data pointed to that may be used uninitialized rather
than the pointer itself.

Secondly, I think there's a case to be made that 'const void *' should
specifically be exempt from this warning: that a void* is not "a pointer to an
object". (The specific call in the original code was to pthread_getspecific();
it seems reasonable that it should take a 'const void *' as its second
argument.)

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-09-15
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I agree about the 'const void *' excemption and about the diagnostic being
misleading because of talking about 'vp1' rather than '*vp1'

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
The text of the warning should be adjusted to make it clear that it's the
object the pointer points to that may be used uninitialized by the function. 
For functions like pthread_getspecific() and pthread_setspecific() that do not
access the object GCC provides attribute access none to suppress the warning:

  extern __attribute__ ((access (none, 1))) void f1 (const void *pointer);

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[hv at crypt dot org]

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

--- Comment #5 from Hugo van der Sanden <hv at crypt dot org> ---
(In reply to Martin Sebor from comment #4)
> For functions like pthread_getspecific() and pthread_setspecific() that do
> not access the object GCC provides attribute access none to suppress the
> warning:
> 
>   extern __attribute__ ((access (none, 1))) void f1 (const void *pointer);

Well that's not a solution for developers of perl, since these system headers
are not under our control. I'm not sure it's a solution right now for
developers of those system headers either, since adding the attribute yields a
different warning under slightly earlier versions of gcc, eg with gcc-9.2.1:
test.c:8:1: warning: 'access' attribute directive ignored [-Wattributes]
    8 | extern int pthread_setspecific (unsigned int key, const void *pointer)
__attribute__ ((access (none, 2)));
      | ^~~~~~

I think we still find the original sort of maybe-uninitialized warnings useful,
so we'll probably just do the useless initialization, and the code will run a
bit slower under gcc.

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
In general a program can add an attribute to a system function by redeclaring
it with it.  This of course needs to be done conditionally on the GCC version
that supports the attribute.  This in turn can be tested at compile time by the
__has_attribute operator or based on GCC version macros.

[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment

[fw at gcc dot gnu.org]

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

Florian Weimer <fw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=28458

--- Comment #7 from Florian Weimer <fw at gcc dot gnu.org> ---
We need to suppress this warning for pthread_setspecific in glibc because it is
incorrect there. There is currently no good way to implement that suppression
unfortunately.

[Bug tree-optimization/102329] [11/12 Regression] pointer "maybe uninitialized" right after assignment

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|pointer "maybe              |[11/12 Regression] pointer
                   |uninitialized" right after  |"maybe uninitialized" right
                   |assignment                  |after assignment
   Target Milestone|---                         |11.3

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There might be another bug referencing the same.

[Bug tree-optimization/102329] [11/12 Regression] pointer "maybe uninitialized" right after assignment

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
The wording should be fixed ASAP, not sure what's blocking that.  It might be
nice to provide a way to separately disable this diagnostic like by introducing
a separate option (no good idea on the naming).

[Bug tree-optimization/102329] [11/12 Regression] pointer "maybe uninitialized" right after assignment

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.3                        |11.4

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.

[Bug tree-optimization/102329] [11/12/13/14 Regression] pointer "maybe uninitialized" right after assignment

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.4                        |11.5

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.