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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Blocks|                            |24639
   Last reconfirmed|                            |2021-05-04
          Component|c                           |tree-optimization
      Known to fail|                            |11.1.0, 12.0
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |diagnostic
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning here is expected (it was considered when the -Wmaybe-uninitialized
enhancement was added) but let me confirm this as a bug for the inconsistency
below and because even though the expected suppression works via attribute
access none, it triggers other unhelpful warnings.  The warning should be
issued consistently and I've become convinced that attribute access none with
no size argument should not expect the pointer points to an object of nonzero
size.

I'm not sure that implementing a heuristic for the likely rare [T*, const T*)
range is worthwhile since it would come at the risk of false negatives.  A
solution I'd like better is extending attribute access to apply two pointer
arguments in addition to pointer and size.

$ (set -x && cat a.c && gcc -D'__attribute__(x)=' -O2 -S -Wall a.c && gcc -O2
-S -Wall a.c)
+ cat a.c
__attribute__ ((access (none, 2)))
void f (int *, const int *);

void f1 (void)
{
  int a[2];
  f (a, a + 1);    // -Wmaybe-uninitialized
}

void f2 (void)
{
  int a[2];
  f (a, a + 2);    // no warning
}

void g1 (void)
{
  int *p = __builtin_malloc (sizeof (*p) * 2);
  f (p, p + 1);    // -Wmaybe-uninitialized
}

void g2 (void)
{
  int *p = __builtin_malloc (sizeof (*p) * 2);
  f (p, p + 2);    // -Wmaybe-uninitialized
}

+ gcc '-D__attribute__(x)=' -O2 -S -Wall a.c
a.c: In function ‘f1’:
a.c:7:3: warning: ‘a’ may be used uninitialized [-Wmaybe-uninitialized]
    7 |   f (a, a + 1);    // -Wmaybe-uninitialized
      |   ^~~~~~~~~~~~
a.c:2:6: note: by argument 2 of type ‘const int *’ to ‘f’ declared here
    2 | void f (int *, const int *);
      |      ^
a.c:6:7: note: ‘a’ declared here
    6 |   int a[2];
      |       ^
a.c: In function ‘g1’:
a.c:19:3: warning: ‘<unknown>’ may be used uninitialized
[-Wmaybe-uninitialized]
   19 |   f (p, p + 1);    // -Wmaybe-uninitialized
      |   ^~~~~~~~~~~~
a.c:2:6: note: by argument 2 of type ‘const int *’ to ‘f’ declared here
    2 | void f (int *, const int *);
      |      ^
a.c: In function ‘g2’:
a.c:25:3: warning: ‘<unknown>’ may be used uninitialized
[-Wmaybe-uninitialized]
   25 |   f (p, p + 2);    // -Wmaybe-uninitialized
      |   ^~~~~~~~~~~~
a.c:2:6: note: by argument 2 of type ‘const int *’ to ‘f’ declared here
    2 | void f (int *, const int *);
      |      ^
+ gcc -O2 -S -Wall a.c
a.c: In function ‘f2’:
a.c:13:3: warning: ‘f’ expecting 4 bytes in a region of size 0
[-Wstringop-overread]
   13 |   f (a, a + 2);    // no warning
      |   ^~~~~~~~~~~~
a.c:12:7: note: at offset 8 into source object ‘a’ of size 8
   12 |   int a[2];
      |       ^
a.c:2:6: note: in a call to function ‘f’ declared with attribute ‘access (none,
2)’
    2 | void f (int *, const int *);
      |      ^
a.c: In function ‘g2’:
a.c:25:3: warning: ‘f’ expecting 4 bytes in a region of size 0
[-Wstringop-overread]
   25 |   f (p, p + 2);    // -Wmaybe-uninitialized
      |   ^~~~~~~~~~~~
a.c:24:12: note: at offset 8 into source object of size 8 allocated by
‘__builtin_malloc’
   24 |   int *p = __builtin_malloc (sizeof (*p) * 2);
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.c:2:6: note: in a call to function ‘f’ declared with attribute ‘access (none,
2)’
    2 | void f (int *, const int *);
      |      ^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

Reply via email to