[Bug c/99295] [9/10/11 Regression] documentation on __attribute__((malloc)) is wrong

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.1, 9.3.0
Summary|[11 Regression] |[9/10/11 Regression]
   |documentation on|documentation on
   |__attribute__((malloc)) is  |__attribute__((malloc)) is
   |wrong   |wrong
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to work|10.2.1  |8.3.0
   Keywords||patch
 Status|NEW |ASSIGNED

--- Comment #3 from Martin Sebor  ---
I agree the insertion of the sentence:

  Compiler predicts that a function with the attribute returns non-null in most
cases.

make the following sentence at least ambiguous if not incorrect. The sentence
was added in r263355, in response to pr83023.

I have posted the following change to avoid the unintended reading:
https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566030.html

[Bug c/99276] grammar in diagnostics for overflowing the destination

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-01
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.

[Bug c/99276] grammar in diagnostics for overflowing the destination

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug c/99317] Missed warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=44209

--- Comment #4 from Martin Sebor  ---
To expand on Andrew's comment: The C rules specify the type of the result of
operator ?: when either of the second and third operands is a pointer to void,
but they do no specify the result type when the operands are pointers to
incompatible types (like int* and float*).  The warning points out the latter.

The C++ rules, OTOH, are more restrictive and make the ?: expression valid only
when the types of the arguments can be implicitly converted to one another. 
Since in C++ a pointer to void isn't implicitly convertible to a pointer to an
object type all the expressions in the test case are invalid.

In C mode, the -Wc++-compat option helps detect C/C++ incompatibilities and
detects this problem (below).  So with that, since the problem is diagnosed
under the right option, I think this report can be resolved as WONTFIX.  (That
the warning in comment #0 is issued unconditionally and not under the control
of a specific option, is a separate problem tracked in in bug 44209.)

$ gcc -S -Wall -Wc++-compat pr99317.c
pr99317.c: In function ‘foo’:
pr99317.c:3:17: warning: request for implicit conversion from ‘void *’ to
‘float *’ not permitted in C++ [-Wc++-compat]
3 | float * f = v;
  | ^
pr99317.c:4:15: warning: request for implicit conversion from ‘void *’ to ‘int
*’ not permitted in C++ [-Wc++-compat]
4 | int * i = w;
  |   ^
pr99317.c:5:19: warning: pointer type mismatch in conditional expression
5 | return (x ? f : i);
  |   ^
pr99317.c:5:19: warning: request for implicit conversion from ‘void *’ to ‘int
*’ not permitted in C++ [-Wc++-compat]
5 | return (x ? f : i);
  |~~~^~~~
pr99317.c: In function ‘foo1’:
pr99317.c:10:17: warning: request for implicit conversion from ‘void *’ to
‘float *’ not permitted in C++ [-Wc++-compat]
   10 | float * f = v;
  | ^
pr99317.c:11:15: warning: request for implicit conversion from ‘void *’ to ‘int
*’ not permitted in C++ [-Wc++-compat]
   11 | int * i = w;
  |   ^
pr99317.c:12:19: warning: request for implicit conversion from ‘void *’ to ‘int
*’ not permitted in C++ [-Wc++-compat]
   12 | return (1 ? f : (void *)i);
  |~~~^~~~
pr99317.c: In function ‘bar’:
pr99317.c:16:17: warning: request for implicit conversion from ‘void *’ to
‘float *’ not permitted in C++ [-Wc++-compat]
   16 | float * f = v;
  | ^
pr99317.c:17:15: warning: request for implicit conversion from ‘void *’ to ‘int
*’ not permitted in C++ [-Wc++-compat]
   17 | int * i = w;
  |   ^
pr99317.c:18:19: warning: request for implicit conversion from ‘void *’ to ‘int
*’ not permitted in C++ [-Wc++-compat]
   18 | return (x ? f : (void *)i);
  |~~~^~~~

[Bug c++/99251] [11 Regression] inconsistent -Wnonnull warning behaviour with dynamic_cast

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Martin Sebor  ---
Fixed in r11-7458.

[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
Bug 95507 depends on bug 99251, which changed state.

Bug 99251 Summary: [11 Regression] inconsistent -Wnonnull warning behaviour 
with dynamic_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99251

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug c/99295] [9/10 Regression] documentation on __attribute__((malloc)) is wrong

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|11.0|
Summary|[9/10/11 Regression]|[9/10 Regression]
   |documentation on|documentation on
   |__attribute__((malloc)) is  |__attribute__((malloc)) is
   |wrong   |wrong
  Known to work||11.0

--- Comment #5 from Martin Sebor  ---
r11-7459 updates the GCC 11 manual.

[Bug middle-end/99276] grammar in diagnostics for overflowing the destination

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c   |middle-end
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Martin Sebor  ---
Fixed.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 99276, which changed state.

Bug 99276 Summary: grammar in diagnostics for overflowing the destination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/99367] New: missing warning on constructing/destroying class objects in insufficient space

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99367
   Summary: missing warning on constructing/destroying class
objects in insufficient space
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Except in the most trivial cases GCC fails to diagnose invalid attempts to
invoke nontrivial constructors or destructors of classes in insufficient space.
 They should be easily detectable in the middle end.

$ cat u.C && gcc -O2 -S -Wall u.C
void* operator new (__SIZE_TYPE__, void *p) { return p; }

struct A { A (); ~A (); int i; };

void f0 (void*);

char a[sizeof (A)];

void f1 ()
{
  A *q = new (a + 1) A ();   // -Wplacement-new (good)
  f0 (q);
}

void g ()
{
  char *p = a + 1;
  A *q = new (p) A ();   // missing warning
  f0 (q);
}

void f2 ()
{
  A *q = (A*)(a + 1);
  q->~A ();  // missing warning
}
u.C: In function ‘void f1()’:
u.C:11:17: warning: placement new constructing an object of type ‘A’ and size
‘4’ in a region of type ‘char [4]’ and size ‘3’ [-Wplacement-new=]
   11 |   A *q = new (a + 1) A ();   // -Wplacement-new (good)
  |   ~~^~~
u.C:7:6: note: at offset 1 from ‘a’ declared here
7 | char a[sizeof (A)];
  |  ^

[Bug middle-end/99370] New: calling a virtual function in insufficient space silently folded to __builtin_unreachable

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99370
   Summary: calling a virtual function in insufficient space
silently folded to __builtin_unreachable
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Related to pr99367, GCC recognizes as invalid calls to virtual functions on a
object stored in a space that's less than the size of its type and folds those
calls to __builtin_unreachable.  That's reasonable, but it should not do that
silently.  The invalid call should also be diagnosed.

$ cat u.C && gcc -O2 -S -Wall -fdump-tree-ccp1=/dev/stdout -fanalyzer u.C
struct A { virtual void f (); int i; };

char a[sizeof (A) + 1];

void f1 ()
{
  A *q = (A*)(a + 1);
  q->f (); // okay
}

void f2 ()
{
  A *q = (A*)(a + 2);
  q->f (); // silently folded to __builtin_unreachable (should also warn)
}

;; Function f1 (_Z2f1v, funcdef_no=0, decl_uid=2364, cgraph_uid=1,
symbol_order=1)

void f1 ()
{
  struct A * q;
  int (*) () * _1;
  int (*) () _2;

   :
  _1 = MEM[(struct A *)&a + 1B]._vptr.A;
  _2 = *_1;
  OBJ_TYPE_REF(_2;(struct A)&MEM  [(void *)&a + 1B]->0) (&MEM
 [(void *)&a + 1B]);
  return;

}



;; Function f2 (_Z2f2v, funcdef_no=1, decl_uid=2367, cgraph_uid=2,
symbol_order=2)

Removing basic block 3
void f2 ()
{
  struct A * q;
  int (*) () * _1;
  int (*) () _2;

   :
  _1 = MEM[(struct A *)&a + 2B]._vptr.A;
  _2 = *_1;
  __builtin_unreachable ();

}

[Bug c/99420] New warning -Warray-parameter

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Sebor  ---
The false positive is caused by the local redeclaration of f1() in h() below
not having had the type attributes added to it describing the form of the
array.  This happens because instead of merging the type attributes from the
previous declaration of f1() in g() into those in h() as is done for f0,
pushdecl() sets them to null (on lines 3525-3562 in c/c-decl.c).   The
difference is due to pushdecl() treating redeclarations of entities that are in
scope (like f0) differently than those that aren't (like f1() in h()).

$ cat u.c && gcc -S -Wall u.c
void f0 (int [1]);
void f0 (int [1]);   // okay

void g (void)
{
  void f1 (int [1]);
}

void h (void)
{
  void f1 (int [1]);   // bogus -Warray-parameter
}

u.c: In function ‘h’:
u.c:11:12: warning: argument 1 of type ‘int[1]’ with mismatched bound
[-Warray-parameter=]
   11 |   void f1 (int [1]);   // bogus -Warray-parameter
  |^~~
u.c:6:12: note: previously declared as ‘int *’
6 |   void f1 (int [1]);
  |^~~

[Bug sanitizer/99418] sanitizer checks for accessing multidimentional VLA-array

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
The initialization of a reference binds it to the value of the initializer
expression.  In both examples the [value of the] initializer expression is
undefined because it doesn't refer to an element of the array.  One way to see
that is in a constexpr context which rejects undefined constructs with an error
(only with Clang; GCC doesn't reject invalid initialization of references
there, see also pr70151):

$ cat t.C && clang -S t.C
constexpr int a[2] = { 1, 2 };
constexpr const int &r = a[2];
t.C:2:26: warning: array index 2 is past the end of the array (which contains 2
  elements) [-Warray-bounds]
constexpr const int &r = a[2];
 ^ ~
t.C:1:1: note: array 'a' declared here
constexpr int a[2] = { 1, 2 };
^
t.C:2:22: error: constexpr variable 'r' must be initialized by a constant
  expression
constexpr const int &r = a[2];
 ^   
t.C:2:22: note: dereferenced pointer past the end of subobject of 'a' is not a
  constant expression
t.C:1:15: note: declared here
constexpr int a[2] = { 1, 2 };
  ^
1 warning and 1 error generated.

[Bug tree-optimization/99473] New: redundant conditional zero-initialization not eliminated

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99473
   Summary: redundant conditional zero-initialization not
eliminated
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

All three functions below should result in equivalently optimal code (and,
ideally IL) but only g1() and g3() result in the same assembly, and only g1()
result in optimal, branchless GIMPLE.

$ cat x.c && gcc -O2 -S -Wall -o/dev/stdout x.c
void f (int*);

void g1 (int i)
{
  int x;
  if (i)
x = i;
  else
x = 0;
  f (&x);
}


void g2 (int i)
{
  int x;
  if (i) {
x = i;
f (&x);
  }
  else {
x = 0;
f (&x);
  }
}

void g3 (int i)
{
  int x = 0;
  if (i)
x = i;
  f (&x);
}
.file   "x.c"
.text
.p2align 4
.globl  g1
.type   g1, @function
g1:
.LFB0:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl%edi, 12(%rsp)
leaq12(%rsp), %rdi
callf
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   g1, .-g1
.p2align 4
.globl  g2
.type   g2, @function
g2:
.LFB1:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
testl   %edi, %edi
je  .L5
movl%edi, 12(%rsp)
leaq12(%rsp), %rdi
callf
addq$24, %rsp
.cfi_remember_state
.cfi_def_cfa_offset 8
ret
.p2align 4,,10
.p2align 3
.L5:
.cfi_restore_state
leaq12(%rsp), %rdi
movl$0, 12(%rsp)
callf
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size   g2, .-g2
.p2align 4
.globl  g3
.type   g3, @function
g3:
.LFB2:
.cfi_startproc
subq$24, %rsp
.cfi_def_cfa_offset 32
movl%edi, 12(%rsp)
leaq12(%rsp), %rdi
callf
addq$24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE2:
.size   g3, .-g3
.ident  "GCC: (GNU) 11.0.1 20210308 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug tree-optimization/97631] [10 Regression] bogus "writing one too many bytes" warning for memcpy with strlen argument

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail|11.0|
Summary|[10/11 Regression] bogus|[10 Regression] bogus
   |"writing one too many   |"writing one too many
   |bytes" warning for memcpy   |bytes" warning for memcpy
   |with strlen argument|with strlen argument
  Known to work||11.0

--- Comment #4 from Martin Sebor  ---
Fixed in GCC 11.

[Bug middle-end/98266] [11 Regression] bogus array subscript is partly outside array bounds on virtual inheritance

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #5 from Martin Sebor  ---
Fixed in r11-7563.

[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 98266, which changed state.

Bug 98266 Summary: [11 Regression] bogus array subscript is partly outside 
array bounds on virtual inheritance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98266

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/99474] New: missing warning on an out of bounds VLA access by a pointer

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99474
   Summary: missing warning on an out of bounds VLA access by a
pointer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The out of bounds access in both functions below should be diagnosed by
-Warray-bounds but only the first one is.

$ cat v.c && gcc -O2 -S -Wall v.c
void f (void*);

void g (void)
{
  int a[5];
  int *p = &a[0];
  p[5] = 0;// -Warray-bounds (good)
  f (a);
}

void h (int n)
{
  if (n > 5)
n = 5;
  int a[n];
  int *p = &a[0];
  p[5] = 0;// missing warning
  f (a);
}

v.c: In function ‘g’:
v.c:7:4: warning: array subscript 5 is outside array bounds of ‘int[5]’
[-Warray-bounds]
7 |   p[5] = 0;// -Warray-bounds (good)
  |   ~^~~
v.c:5:7: note: while referencing ‘a’
5 |   int a[5];
  |   ^

[Bug tree-optimization/99475] New: [10/11 Regression] bogus -Warray-bounds accessing an array element of empty structs

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99475
   Summary: [10/11 Regression] bogus -Warray-bounds accessing an
array element of empty structs
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

An indirect access to an element of an array of empty structs through a pointer
to such an element triggers a spurious -Warray-bounds warning:

$ cat v.c && gcc -O2 -S -Wall v.c
struct S { } a[5];

void f (void)
{
  a[1] = (struct S) { };   // okay
}

void g (void)
{
  struct S *p = &a[0];
  p[1] = (struct S) { };   // bogus -Warray-bounds
}

v.c: In function ‘g’:
v.c:11:4: warning: array subscript 0 is outside array bounds of ‘struct S[5]’
[-Warray-bounds]
   11 |   p[1] = (struct S) { };
  |   ~^~~
v.c:1:14: note: while referencing ‘a’
1 | struct S { } a[5];
  |  ^

[Bug tree-optimization/99475] [10/11 Regression] bogus -Warray-bounds accessing an array element of empty structs

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0
 Status|UNCONFIRMED |NEW
  Known to work||9.3.0
 Blocks||56456
   Last reconfirmed||2021-03-08
   Keywords||diagnostic
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Bisection points to commit d893b683f40884cd00b5beb392566ecc7b67f721:

Author: Martin Sebor 
Date:   Thu Jul 19 23:36:34 2018 +

PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds
index into an array

PR tree-optimization/84047 - missing -Warray-bounds on an out-of-bounds
index into an array
PR tree-optimization/83776 - missing -Warray-bounds indexing past the end
of a string literal

gcc/ChangeLog:

PR tree-optimization/84047
PR tree-optimization/83776
* tree-vrp.c (vrp_prop::check_mem_ref): New function.
(check_array_bounds): Call it.

gcc/testsuite/ChangeLog:

PR tree-optimization/83776
PR tree-optimization/84047
* gcc.dg/Warray-bounds-29.c: New test.
* gcc.dg/Warray-bounds-30.c: New test.
* gcc.dg/Warray-bounds-31.c: New test.
* gcc.dg/Warray-bounds-32.c: New test.

From-SVN: r262893


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/99475] [10/11 Regression] bogus -Warray-bounds accessing an array element of empty structs

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566450.html

[Bug sanitizer/99418] more cases where -fsanitize=bounds can check one-past-the-end accesses

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||56456
 Status|WAITING |NEW
   Keywords||diagnostic

--- Comment #9 from Martin Sebor  ---
I don't know enough about the sanitizer to judge how difficult it might be to
handle this case but a patch I posted in November
(https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558775.html) enhances
-Warray-bounds to diagnose the test cases in comment #8:

$ g++ -O2 -S -Wall pr99418-c8.C
pr99418-c8.C: In function ‘void f()’:
pr99418-c8.C:7:10: warning: unused variable ‘p’ [-Wunused-variable]
7 | int& p = a[10]; // (1)
  |  ^
pr99418-c8.C:8:6: warning: subscript 10 in argument 1 to ‘void g(int&)’ is just
past the end of ‘int [10]’ [-Warray-bounds]
8 | g(a[10]);   // (2)
  | ~^~~
pr99418-c8.C:6:9: note: at offset 40 into source object ‘a’ of size 40
6 | int a[10];
  | ^

The enhancement doesn't handle multidimensional VLAs like those in comment #1
but it looks like the IL has enough information to make the detection possible:

int main ()
{
  int[0:D.2590][0:D.2587] * mas.4;
  int * _4;

   [local count: 1073741824]:
  mas.4_3 = __builtin_alloca_with_align (48, 32);
  _4 = &MEM  [(int[0:D.2569][0:D.2565]
*)mas.4_3][3]{lb: 0 sz: 12}[3];
  escape (_4);
  return 0;

}

With that let me confirm this request for both -Warray-bounds (I'll resubmit
the patch for GCC 12) and for the sanitizer.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug tree-optimization/99489] [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-03-09
Summary|internal compiler error:|[11 Regression] internal
   |during GIMPLE pass: strlen  |compiler error: during
   |in  |GIMPLE pass: strlen in
   |dlt_logstorage_log_file_nam |dlt_logstorage_log_file_nam
   |e() |e()
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code

--- Comment #2 from Martin Sebor  ---
Confirmed with a native x86_64 compiler and the full backtrace below.  It's
most likely a regression introduced in
g:7f5ff78ff3f971c11ec67f422b2fd34281db9123.

during GIMPLE pass: strlen
/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux-musl/dlt-daemon/2.18.6-r0/git/src/offlinelogstorage/dlt_offline_logstorage_behavior.c:
In function ‘dlt_logstorage_log_file_name.part.0’:
/mnt/b/yoe/master/build/tmp/work/cortexa72-yoe-linux-musl/dlt-daemon/2.18.6-r0/git/src/offlinelogstorage/dlt_offline_logstorage_behavior.c:54:6:
internal compiler error: gimple check: expected gimple_call(error_mark), have
gimple_nop() in gimple_call_fndecl, at gimple.h:3171
0xe66115 gimple_check_failed(gimple const*, char const*, int, char const*,
gimple_code, tree_code)
/src/gcc/master/gcc/gimple.c:1259
0xbb23bf GIMPLE_CHECK2
/src/gcc/master/gcc/gimple.h:74
0xb7bbe1 gimple_call_fndecl
/src/gcc/master/gcc/gimple.h:3171
0xb8edf0 gimple_call_alloc_size(gimple*, generic_wide_int*,
range_query*)
/src/gcc/master/gcc/builtins.c:4931
0x15cc71e handle_builtin_stxncpy_strncat
/src/gcc/master/gcc/tree-ssa-strlen.c:3108
0x15caea9 handle_builtin_strncat
/src/gcc/master/gcc/tree-ssa-strlen.c:2666
0x15d214f strlen_check_and_optimize_call
/src/gcc/master/gcc/tree-ssa-strlen.c:5165
0x15d2d30 check_and_optimize_stmt
/src/gcc/master/gcc/tree-ssa-strlen.c:5373
0x15d3917 strlen_dom_walker::before_dom_children(basic_block_def*)
/src/gcc/master/gcc/tree-ssa-strlen.c:5625
0x22901c2 dom_walker::walk(basic_block_def*)
/src/gcc/master/gcc/domwalk.c:309
0x15d3c0e printf_strlen_execute
/src/gcc/master/gcc/tree-ssa-strlen.c:5691
0x15d3fa4 execute
/src/gcc/master/gcc/tree-ssa-strlen.c:5813
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/99489] [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=82429
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #5 from Martin Sebor  ---
Reduced test case (the stpcpy declaration is important because of the hack
described in pr82429):

$ cat v.c && gcc -O2 -S -Wall v.c
char *stpcpy (char *, const char *);

void f (char *d, char c, char *s)
{
  __builtin_strcat (d, s);
  __builtin_strncat (d, &c, 1);
}
during GIMPLE pass: strlen
v.c: In function ‘f’:
v.c:3:6: internal compiler error: gimple check: expected
gimple_call(error_mark), have gimple_nop() in gimple_call_fndecl, at
gimple.h:3171
3 | void f (char *d, char c, char *s)
  |  ^
0xe66115 gimple_check_failed(gimple const*, char const*, int, char const*,
gimple_code, tree_code)
/src/gcc/master/gcc/gimple.c:1259
0xbb23bf GIMPLE_CHECK2
/src/gcc/master/gcc/gimple.h:74
0xb7bbe1 gimple_call_fndecl
/src/gcc/master/gcc/gimple.h:3171
0xb8edf0 gimple_call_alloc_size(gimple*, generic_wide_int*,
range_query*)
/src/gcc/master/gcc/builtins.c:4931
0x15cc71e handle_builtin_stxncpy_strncat
/src/gcc/master/gcc/tree-ssa-strlen.c:3109
0x15caea9 handle_builtin_strncat
/src/gcc/master/gcc/tree-ssa-strlen.c:2666
0x15d214f strlen_check_and_optimize_call
/src/gcc/master/gcc/tree-ssa-strlen.c:5166
0x15d2d30 check_and_optimize_stmt
/src/gcc/master/gcc/tree-ssa-strlen.c:5374
0x15d3917 strlen_dom_walker::before_dom_children(basic_block_def*)
/src/gcc/master/gcc/tree-ssa-strlen.c:5626
0x22901c2 dom_walker::walk(basic_block_def*)
/src/gcc/master/gcc/domwalk.c:309
0x15d3c0e printf_strlen_execute
/src/gcc/master/gcc/tree-ssa-strlen.c:5692
0x15d3fa4 execute
/src/gcc/master/gcc/tree-ssa-strlen.c:5814
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/82429] strcpy to stpcpy transformation disabled in strict mode

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0
   Last reconfirmed||2021-03-09

--- Comment #3 from Martin Sebor  ---
Confirmed.  Changing the optimizer behavior based on whether or not something
unused has been declared makes changing the optimization error-prone and tricky
to test (e.g., pr99489).

[Bug tree-optimization/99489] [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||88781
   Keywords||patch

--- Comment #6 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-March/566510.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
[Bug 88781] [meta-bug] bogus/missing -Wstringop-truncation warnings

[Bug tree-optimization/99502] New: missing -Warray-bounds on partial out of bounds access in C++

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99502
   Summary: missing -Warray-bounds on partial out of bounds access
in C++
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The program below triggers two instances of -Warray-bounds when compiled as C
code but only one when compiled as C++.  This is a regression introduced in 
r11-7563.

$ cat u.C && gcc -O2 -S -Wall u.C
typedef struct A { int i; } A;

char a[sizeof (A) - 1];

void f (A x)
{
  A *p = (A*)a;
  *p = x;  // -Warray-bounds (good)
}

void g (void)
{
  A *p = (A*)a;
  p->i = 0;// missing warning in C++
}

u.C: In function ‘void f(A)’:
u.C:8:6: warning: array subscript ‘A[0]’ is partly outside array bounds of
‘char [3]’ [-Warray-bounds]
8 |   *p = x;  // -Warray-bounds (good)
  |   ~~~^~~
u.C:3:6: note: while referencing ‘a’
3 | char a[sizeof (A) - 1];
  |  ^

[Bug tree-optimization/99502] missing -Warray-bounds on partial out of bounds access in C++

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-10
   Keywords||diagnostic
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

[Bug middle-end/99525] New: wrong location of implicitly generated assignment to polymorphic class

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99525
   Summary: wrong location of implicitly generated assignment to
polymorphic class
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The first warning points to the assignment expression in the calling function. 
But the second warning instead points to the class head instead, making it
difficult to see what caused it.  It too should point to the assignment
expression in the calling function.

The wrong location is first seen in the einline dump.

$ cat x.C && gcc -O2 -S -Wall -fdump-tree-einline-lineno=/dev/stdout x.C
struct X
{
  int i;
};

char a[sizeof (X) - 1];

void f (X x)
{
  X *p = (X*)a;
  *p = x;
}

struct Y
{
  int i;
  virtual ~Y ();
};

void f (Y y)
{
  Y *p = (Y*)a;
  *p = y;
}

;; Function f (_Z1f1X, funcdef_no=0, decl_uid=2351, cgraph_uid=1,
symbol_order=1)

Iterations: 0
void f (struct X x)
{
  struct X * p;

   :
  [x.C:10:6] p_1 = [x.C:10:14] &a;
  [x.C:11:6] [x.C:11:6] *p_1 = x;
  [x.C:12:1] return;

}



;; Function Y::operator= (_ZN1YaSERKS_, funcdef_no=2, decl_uid=2391,
cgraph_uid=2, symbol_order=2)

Iterations: 0
struct Y & Y::operator= (struct Y * const this, const struct Y & D.2392)
{
  int _1;
  struct Y & _6;

   :
  [x.C:14:8] _1 = _3(D)->i;
  [x.C:14:8] this_4(D)->i = _1;
  [x.C:14:8] _6 = this_4(D);
  [x.C:14:8] return _6;

}



;; Function f (_Z1f1Y, funcdef_no=1, decl_uid=2388, cgraph_uid=3,
symbol_order=3)

Iterations: 1

Symbols to be put in SSA form
{ D.2402 }
Incremental SSA update started at block: 0
Number of blocks in CFG: 5
Number of blocks to update: 4 ( 80%)


Merging blocks 2 and 4
Merging blocks 2 and 3
void f (struct Y & y)
{
  struct Y * p;
  int _5;

   :
  [x.C:22:6] p_1 = [x.C:22:14] &a;
  [x.C:14:8] _5 = MEM[(const struct Y &)y_3(D)].i;
  [x.C:14:8] p_1->i = _5;
  [x.C:24:1] return;

}


x.C: In function ‘void f(X)’:
x.C:11:6: warning: array subscript ‘X[0]’ is partly outside array bounds of
‘char [3]’ [-Warray-bounds]
   11 |   *p = x;
  |   ~~~^~~
x.C:6:6: note: while referencing ‘a’ of size 0
6 | char a[sizeof (X) - 1];
  |  ^
x.C: In function ‘void f(Y)’:
x.C:14:8: warning: array subscript ‘Y[0]’ is partly outside array bounds of
‘char [3]’ [-Warray-bounds]
   14 | struct Y
  |^
x.C:6:6: note: while referencing ‘a’ of size 0
6 | char a[sizeof (X) - 1];
  |  ^

[Bug middle-end/99525] wrong location of implicitly generated assignment to polymorphic class

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Martin Sebor  ---
The (otherwise untested) change below corrects the location:

diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 1dcb31c0267..c77745b788d 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -4938,7 +4938,7 @@ expand_call_inline (basic_block bb, gimple *stmt,
copy_body_data *id,
   /* Record the function we are about to inline.  */
   id->src_fn = fn;
   id->src_cfun = DECL_STRUCT_FUNCTION (fn);
-  id->reset_location = DECL_IGNORED_P (fn);
+  id->reset_location = DECL_IGNORED_P (fn) || DECL_ARTIFICIAL (fn);
   id->call_stmt = call_stmt;

   /* When inlining into an OpenMP SIMD-on-SIMT loop, arrange for new automatic

[Bug tree-optimization/99532] New: missing warning on placement new into smaller space

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99532
   Summary: missing warning on placement new into smaller space
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Neither of the two buffer overflows below is diagnosed but they both should be.
 The difference between the two is that the first uses direct access to the
array (i.e,, COMPONENT_REF) while the second direct access to the enclosing
object (MEM_REF).  The missing warning for the former is due to pr99502 but the
latter is something else.

$ cat x.C && gcc -O2 -S -Wall -fdump-tree-vrp1=/dev/stdout x.C
void* operator new (__SIZE_TYPE__, void *p) { return p; }

struct A4 { char a[4]; };
struct A8 { char a[8]; };

void* f ()
{
  void *p = __builtin_malloc (3);
  return new (p) A4 ();   // missing warning
}

void* g ()
{
  void *p = __builtin_malloc (7);
  return new (p) A8 ();   // missing warning
}

;; Function operator new (_ZnwmPv, funcdef_no=0, decl_uid=2348, cgraph_uid=1,
symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

Value ranges after VRP:



void * operator new (long unsigned int D.2346, void * p)
{
   [local count: 1073741824]:
  return p_1(D);

}



;; Function f (_Z1fv, funcdef_no=1, decl_uid=2356, cgraph_uid=2,
symbol_order=1)

;; 2 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

p_11 -> { p_5 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 16
Number of blocks to update: 1 (  6%)



Value ranges after VRP:

p_5: void * VARYING
p_11: void * [1B, +INF]  EQUIVALENCES: { p_5 } (1 elements)


void * f ()
{
  void * p;

   [local count: 268435456]:
  p_5 = __builtin_malloc (3);
  MEM[(struct A4 *)p_5].a[0] = 0;
  MEM[(struct A4 *)p_5].a[1] = 0;
  MEM[(struct A4 *)p_5].a[2] = 0;
  MEM[(struct A4 *)p_5].a[3] = 0;
  return p_5;

}



;; Function g (_Z1gv, funcdef_no=2, decl_uid=2385, cgraph_uid=3,
symbol_order=2)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

p_5 -> { p_3 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 3
Number of blocks to update: 1 ( 33%)



Value ranges after VRP:

p_3: void * VARYING
p_5: void * [1B, +INF]  EQUIVALENCES: { p_3 } (1 elements)


void * g ()
{
  void * p;

   [local count: 1073741824]:
  p_3 = __builtin_malloc (7);
  MEM[(struct A8 *)p_3] = {};
  return p_3;

}

[Bug c/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The warning is by design.  Its purpose is to detect invalid accesses at
non-zero offsets to null pointers, like in the memset call below:

  struct S { int a, b[4]; };

  void f (struct S *p)
  {
if (p) return;
memset (p->b, 0, 4 * sizeof p->b);
  }

For now, I recommend suppressing the warning either by #pragma GCC diagnostic
or by making the pointer volatile.  In the future, providing an attribute to
annotate constant addresses with (or extending the io() attribute supported by
some targets to all targets) might be another way to avoid it.

[Bug tree-optimization/99489] [11 Regression] internal compiler error: during GIMPLE pass: strlen in dlt_logstorage_log_file_name()

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Martin Sebor  ---
Fixed in r11-7658.

[Bug middle-end/88781] [meta-bug] bogus/missing -Wstringop-truncation warnings

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781
Bug 88781 depends on bug 99489, which changed state.

Bug 99489 Summary: [11 Regression] internal compiler error: during GIMPLE pass: 
strlen in dlt_logstorage_log_file_name()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99489

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/99580] False positive -Warray-bounds with -O2

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Ever confirmed|0   |1
  Component|c++ |tree-optimization
  Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0,
   ||9.2.0
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-03-14
 Blocks||56456
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
Confirmed.  The warning first appeared with r238761 AKA "Teach VRP to register
assertions along default switch labels (PR18046)."

A simplified test case is below:

$ cat pr99580.C && -O2 -S -Wall -fdump-tree-vrp1-details pr99580.C
struct vec
{
  int operator[] (int i)
  {
switch (i) {
default:
case 0: return x;
case 1: return y;
case 2: return z;
}
  }

  int x, y, z;
};

vec v[3];

int f ()
{
  int max_el = v[0][1];
  int max_j = 1;

  for (int i = 0; i < 3; i++)
for (int j = i + 1; j < 3; j++)
  if (v[i][j] > max_el)
max_j = j;

  return v[max_j][max_j];
}
pr99580.C: In function ‘int f()’:
pr99580.C:28:17: warning: array subscript 3 is above array bounds of ‘vec [3]’
[-Warray-bounds]
   28 |   return v[max_j][max_j];
  |  ~~~^
pr99580.C:16:5: note: while referencing ‘v’
   16 | vec v[3];
  | ^

$ grep warning pr99580.C.110t.vrp1 
Array bound warning for MEM  [(struct vec *)&v][max_j_27]

And:

Simulating block 14

extract_range_from_stmt visiting:
max_j_27 = ASSERT_EXPR  1>;
Intersecting
  int ~[1, 2]  EQUIVALENCES: { max_j_21 } (1 elements)
and
  int [1, 2147483646]
to
  int [3, 2147483646]  EQUIVALENCES: { max_j_21 } (1 elements)
Intersecting
  int [3, 2147483646]  EQUIVALENCES: { max_j_21 } (1 elements)
and
  int VARYING
to
  int [3, 2147483646]  EQUIVALENCES: { max_j_21 } (1 elements)
Found new range for max_j_27: int [3, 2147483646]  EQUIVALENCES: { } (0
elements)
Adding destination of edge (14 -> 17) to worklist


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||diagnostic

--- Comment #4 from Martin Sebor  ---
Most warnings designed to detect invalid accesses (not just -Wstringop-overread
but also -Wstringop-overflow and -Wformat-overflow/-truncation, -Wrestrict, and
some forms of -Warray-bounds) use the same underlying code to determine the
identity of the accessed object, so they all should trigger if they see a
constant address.

But I tested the warning with the kernel when I implemented it months ago and
don't think I saw any instances of it (though I don't see sharpsl_param in any
of my logs).  I still don't.  How many do you see?

Here's the list of -Wstringop- warnings in my fresh build but I'm never sure I
use the right target.  Is allyesconfig the right one?

$ grep Wstringop-over /src/linux-stable/gcc-master.log 
arch/x86/mm/pgtable.c:437:13: warning: ‘preallocate_pmds.constprop’ accessing 8
bytes in a region of size 0 [-Wstringop-overflow=]
arch/x86/mm/pgtable.c:440:13: warning: ‘preallocate_pmds.constprop’ accessing 8
bytes in a region of size 0 [-Wstringop-overflow=]
arch/x86/mm/pgtable.c:462:9: warning: ‘free_pmds.constprop’ accessing 8 bytes
in a region of size 0 [-Wstringop-overflow=]
arch/x86/mm/pgtable.c:455:9: warning: ‘pgd_prepopulate_user_pmd’ accessing 8
bytes in a region of size 0 [-Wstringop-overflow=]
arch/x86/mm/pgtable.c:464:9: warning: ‘free_pmds.constprop’ accessing 8 bytes
in a region of size 0 [-Wstringop-overflow=]
mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
mm/mempolicy.c:3001:26: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
drivers/gpu/drm/i915/intel_pm.c:3093:9: warning: ‘intel_read_wm_latency’
accessing 16 bytes in a region of size 10 [-Wstringop-overflow=]
drivers/gpu/drm/i915/intel_pm.c:3057:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/intel_pm.c:3058:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/intel_pm.c:3059:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/intel_pm.c:3086:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/intel_pm.c:3087:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/intel_pm.c:3088:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/intel_pm.c:3103:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/intel_pm.c:3104:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/intel_pm.c:3105:9: warning: ‘intel_print_wm_latency’
reading 16 bytes from a region of size 10 [-Wstringop-overread]
drivers/gpu/drm/i915/display/intel_dp.c:4556:22: warning:
‘drm_dp_channel_eq_ok’ reading 6 bytes from a region of size 4
[-Wstringop-overread]

The full breakdown with the warnings forcefully disabled in the top-level
Makefile re-enabled is below:

DiagnosticCount   UniqueFiles
-Wmissing-prototypes759  248  114
-Wunused-const-variable=391  233   31
-Wformat-truncation=311  297  229
-Wmaybe-uninitialized   158  133  103
-Wunused-but-set-variable   143  137   88
-Warray-bounds   94   32   12
-Wzero-length-bounds 69   66   16
-Wsuggest-attribute=format   60   26   21
-Wnested-externs 4111
-Woverride-init  36   22   15
-Wrestrict   23   14   10
-Wformat-overflow=   20   19   15
-Wempty-body 15   158
-Wstringop-overflow= 1273
-Wmisleading-indentation 1122
-Wcast-function-type 1122
-Wstringop-overread  10   102
-Wenum-conversion

[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Martin Sebor  ---
(In reply to Arnd Bergmann from comment #6)
> I figured out the qnx4 warning in the end: https://godbolt.org/z/hvqjr3

The false positive is a known problem caused by redundancy elimination (the
FRE/PRE passes) substituting one member for another when they both refer to the
same address.  It often happens with union members that share the same starting
offset but can also happen with struct members in code that refers to both the
end of one and the beginning of the next member with no intervening padding.

There's no particular reason why it picks one or the other member (maybe it
picks whichever it sees first in some order, I don't know), but the warning
only triggers when it substitutes the smaller of the two members in a larger
access.  In the strnlen test case w/o sanitization it happens to pick the
bigger member.  This can be seen in the output of -fdump-tree-pre-details:

Inserted pretmp_12 = &de_9(D)->D.2393.D.2392.dl_fname;
 in predecessor 3 (0004)
Replaced &de_9(D)->D.2393.D.2392.dl_fname with pretmp_12 in all uses of _5 =
&de_9(D)->D.2393.D.2392.dl_fname;
Replaced &de_9(D)->D.2393.D.2389.di_fname with pretmp_12 in all uses of _3 =
&de_9(D)->D.2393.D.2389.di_fname;
Removing dead stmt _3 = &de_9(D)->D.2393.D.2389.di_fname;
Removing dead stmt _5 = &de_9(D)->D.2393.D.2392.dl_fname;

The instrumentation introduced by the sanitizers changes the IL in ways that
affect the choices made by subsequent transformations.  In this case, the
sanitizer first inserts a call to __builtin___tsan_read1() to record the access
to di_fname[0].  The sanitizers run after PRE but before some FRE iterations. 
The resulting IL from the thread sanitizer looks like this:

   [local count: 1073741824]:
  _13 = __builtin_return_address (0);
  __builtin___tsan_func_entry (_13);
  _5 = &de_9(D)->D.2390.D.2386.di_fname[0];
  __builtin___tsan_read1 (_5);<<< record access to
di_fname[0]
  _1 = de_9(D)->D.2390.D.2386.di_fname[0];
  if (_1 == 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 365072224]:
  goto ; [100.00%]

   [local count: 708669601]:
  _3 = &de_9(D)->di_status;
  __builtin___tsan_read1 (_3);
  _2 = de_9(D)->di_status;
  pretmp_12 = &de_9(D)->D.2390.D.2389.dl_fname;   <<< temporary added by PRE
  if (_2 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 354334800]:
  _4 = __builtin_strnlen (pretmp_12, 16);
  _11 = (int) _4;
  goto ; [100.00%]

   [local count: 354334800]:
  _6 = __builtin_strnlen (pretmp_12, 48);
  _10 = (int) _6;

   [local count: 1073741824]:
  # _7 = PHI <0(7), _11(4), _10(5)>
  __builtin___tsan_func_exit ();
  return _7;

}

The IL above is then changed by FRE which replaces dl_fname with di_fname:

Value numbering stmt = pretmp_12 = &de_9(D)->D.2390.D.2389.dl_fname;
Setting value number of pretmp_12 to _5 (changed)
_5 is available for _5
Replaced &de_9(D)->D.2390.D.2389.dl_fname with _5 in all uses of pretmp_12 =
&de_9(D)->D.2390.D.2389.dl_fname;

The warning is then issued by the strlen pass that runs after FRE5 and that
sees the IL below:

   [local count: 1073741824]:
  _13 = __builtin_return_address (0);
  __builtin___tsan_func_entry (_13);
  _5 = &de_9(D)->D.2393.D.2389.di_fname[0];   <<< inserted by sanitizer
  __builtin___tsan_read1 (_5);<<< record access to di_fname[0] 
  _1 = de_9(D)->D.2393.D.2389.di_fname[0];<<< inserted by FRE5
  if (_1 == 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 708669601]:
  _3 = &de_9(D)->di_status;
  __builtin___tsan_read1 (_3);
  _2 = de_9(D)->di_status;
  if (_2 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 354334800]:
  _4 = strnlen (_5, 16);
  _11 = (int) _4;
  goto ; [100.00%]

   [local count: 354334800]:
  _6 = strnlen (_5, 48);  <<< -Wstringop-overread
  _10 = (int) _6;

   [local count: 1073741824]:
  # _7 = PHI <0(2), _11(4), _10(5)>
  __builtin___tsan_func_exit ();
  return _7;

}

I'm hoping to change PRE/FRE in GCC 12 to replace the member substitution with
one involving &object + offsetof (type, memer).  That will avoid the false
positives in these cases with no adverse impact on optimization.

[Bug middle-end/99578] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Martin Sebor  ---
(In reply to Richard Biener from comment #7)
> Note heuristically 0xe8ffc000 isn't likely such an offset from a NULL
> pointer object because the object would be quite large.
> 
> The diagnostic could maybe also clarify that it assumes 0xe8ffc000 is an
> offsetted NULL pointer.

I can do that in stage 1 when I convert the warning to use the access_ref class
(that exposes this information).

A better solution we discussed with Jeff is to issue -Wnonnull when a member
access through a null pointer is first detected.  Using something like
__builtin_warning for that would help avoid false positives when this happens
early on (in the test case in comment #1 that's in EVRP).

[Bug middle-end/99612] Remove "#pragma GCC system_header" from atomic file to warn on incorrect memory order

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-16
   Target Milestone|--- |12.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98871
 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
  Component|libstdc++   |middle-end
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
The root cause is the same as the limitation discussed in pr98871.  Warnings
issued from the middle end cannot be controlled with sufficient flexibility. 
The patch attached to the bug should in principle resolve this as well.  Let me
assign this to myself and handle it for GCC 12.

That said, when reporting bugs, please include all the information in the bug
we request in https://gcc.gnu.org/bugs/#need, in particular the full test case,
the command line options used to compile it, and the compiler output.  Links to
third party sites are not sufficient (as GCC on Godbolt changes, so might the
symptoms).

[Bug middle-end/99612] Remove "#pragma GCC system_header" from atomic file to warn on incorrect memory order

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
  Known to fail||11.0

[Bug middle-end/99612] Remove "#pragma GCC system_header" from atomic file to warn on incorrect memory order

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Sebor  ---
The test case:

$ (set -x && cat pr99612.C && g++ -O2 -S -Wall --std=c++20 -O2 -Wall
-Winvalid-memory-model pr99612.C && g++ -O2 -S -Wall --std=c++20 -O2 -Wall
-Winvalid-memory-model -Wsystem-headers pr99612.C)
+ cat pr99612.C
#include 

std::atomic a;

int f() {
  auto ret = a.load(std::memory_order_release);
  a.store(10, std::memory_order_acquire);
  return ret;
}
+ g++ -O2 -S -Wall --std=c++20 -O2 -Wall -Winvalid-memory-model pr99612.C
+ /g++ -O2 -S -Wall --std=c++20 -O2 -Wall -Winvalid-memory-model
-Wsystem-headers pr99612.C
In file included from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/atomic:41,
 from pr99612.C:1:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:
In function ‘int f()’:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:479:31:
warning: invalid memory model for ‘__atomic_load’ [-Winvalid-memory-model]
  479 | return __atomic_load_n(&_M_i, int(__m));
  |   ^
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h:455:25:
warning: invalid memory model for ‘__atomic_store’ [-Winvalid-memory-model]
  455 | __atomic_store_n(&_M_i, __i, int(__m));
  | ^

[Bug middle-end/99630] New: missing -Warray-bounds accessing a trailing array of a virtual base class

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99630
   Summary: missing -Warray-bounds accessing a trailing array of a
virtual base class
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC issues -Warray-bounds for the out of bounds access to an object with an
ordinary base class in f() but not for the same out of bounds access to an
object with a virtual base class in g().  Both access should be diagnosed.

The problem is that trailing_array() calls array_at_struct_end_p() which
returns true for trailing array members without considering the type of the
enclosing object.

$ cat u.C && gcc -O2 -S -Wall -fdump-tree-vrp1=/dev/stdout u.C
struct A1
{
  virtual ~A1 ();
  int a1a[1];
};

struct A2
{
  virtual ~A2 ();
  int a2a[1];
};

struct B1: A1 { };
struct B2: A2 { };
struct D1: B1, B2 { };

void f (D1 *p)
{
  extern D1 d1;
  p->a1a[0] = (char*)d1.a1a - (char*)&d1;
  p->a1a[1] = (char*)d1.a2a - (char*)&d1;   // -Warray-bounds (good)
}

struct V1: virtual A1 { };
struct V2: virtual A2 { };

struct D2: V1, V2 { };

void f (D2 *p)
{
  extern D2 d2;
  p->a1a[0] = (char*)d2.a1a - (char*)&d2;
  p->a1a[1] = (char*)d2.a2a - (char*)&d2;   // missing -Warray-bounds
}

;; Function f (_Z1fP2D1, funcdef_no=0, decl_uid=2468, cgraph_uid=1,
symbol_order=0)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

p_5 -> { p_2(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 3
Number of blocks to update: 1 ( 33%)



Value ranges after VRP:

p_2(D): struct D1 * VARYING
p_5: struct D1 * [1B, +INF]  EQUIVALENCES: { p_2(D) } (1 elements)


u.C: In function ‘void f(D1*)’:
u.C:21:11: warning: array subscript 1 is above array bounds of ‘int [1]’
[-Warray-bounds]
   21 |   p->a1a[1] = (char*)d1.a2a - (char*)&d1;   // -Warray-bounds (good)
  |   ^
u.C:4:7: note: while referencing ‘A1::a1a’
4 |   int a1a[1];
  |   ^~~
void f (struct D1 * p)
{
   [local count: 1073741824]:
  p_2(D)->D.2450.D.2409.a1a[0] = 8;
  p_2(D)->D.2450.D.2409.a1a[1] = 24;
  return;

}



;; Function f (_Z1fP2D2, funcdef_no=1, decl_uid=2566, cgraph_uid=2,
symbol_order=1)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

_9 -> { _4 }
p_10 -> { p_6(D) }
Incremental SSA update started at block: 2
Number of blocks in CFG: 3
Number of blocks to update: 1 ( 33%)



Value ranges after VRP:

_1: int (*) () * VARYING
_2: long int VARYING
_3: sizetype VARYING
_4: struct D2 * [1B, +INF]
p_6(D): struct D2 * VARYING
_9: struct D2 * [1B, +INF]  EQUIVALENCES: { _4 } (1 elements)
p_10: struct D2 * [1B, +INF]  EQUIVALENCES: { p_6(D) } (1 elements)


void f (struct D2 * p)
{
  int (*) () * _1;
  long int _2;
  sizetype _3;
  struct D2 * _4;

   [local count: 1073741824]:
  _1 = p_6(D)->D.2549._vptr.V1;
  _2 = MEM[(long int *)_1 + -24B];
  _3 = (sizetype) _2;
  _4 = p_6(D) + _3;
  MEM[(struct A1 *)_4].a1a[0] = 24;
  MEM[(struct A1 *)_4].a1a[1] = 40;   <<< _4's type is D2 and a1a[1] overlaps
its _vptr
  return;

}

[Bug middle-end/99630] missing -Warray-bounds accessing a trailing array of a virtual base class

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Martin Sebor  ---
It might be worth warning for any out of bounds access to trailing members of
polymorphic classes, regardless of whether the type of the complete enclosing
object is known (and known to be derived virtually).

[Bug tree-optimization/99632] New: missing warning accessing a trailing zero length array member of base class

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99632
   Summary: missing warning accessing a trailing zero length array
member of base class
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

-Warray-bounds triggers for the invalid access in f() and g() but not in h(). 
All three should be diagnosed.  In addition, the warning in g() should be on
the line with the access.

$ cat t.C && gcc -O2 -S -Wall t.C
struct D: B { int j; };

void f (D *p, int i)
{
  p->a[i] = 0; // -Warray-bounds (good)
}

void g (D *p, int i)
{
  int *q = &p->a[i];   //-Warray-bounds (should be on next line)
  *q = 0; 
}

void h (D *p, int i)
{
  int *q = p->a;
  q[i] = 0;// missing warning
}


t.C: In function ‘void f(D*, int)’:
t.C:6:9: warning: array subscript i is outside array bounds of ‘int [0]’
[-Warray-bounds]
6 |   p->a[i] = 0; // -Warray-bounds (good)
  |   ~~^
t.C:1:19: note: while referencing ‘B::a’
1 | struct B { int n, a[0]; };
  |   ^
t.C: In function ‘void g(D*, int)’:
t.C:11:19: warning: array subscript i is outside array bounds of ‘int [0]’
[-Warray-bounds]
   11 |   int *q = &p->a[i];   //-Warray-bounds (should be on next line)
  | ~~^
t.C:1:19: note: while referencing ‘B::a’
1 | struct B { int n, a[0]; };
  |   ^

[Bug tree-optimization/99632] missing warning accessing a trailing zero length array member of base class

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Martin Sebor  ---
The definition missing from comment #0 is:

  struct B { int n, a[0]; };

[Bug tree-optimization/99635] New: -Warray-bounds where -Wzero-length-bounds is expected

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99635
   Summary: -Warray-bounds where -Wzero-length-bounds is expected
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The store to p->da[1] is out of bounds and diagnosed as expected.  The store to
p->da[0], however, is in bounds but overlaps with p->b0i and so should be
diagnosed by -Wzero-length-bounds.

$ cat t.C && gcc -O2 -S -fdump-tree-vrp1=/dev/stdout -Wall t.C
inline void* operator new (__SIZE_TYPE__, void *p) { return p; }

struct B0 { int b0i; };
struct B1: virtual B0 { };
struct B2: virtual B0 { };
struct D: B1, B2 { int di, da[0]; };

void* f ()
{
  D *p = (D*)new char[sizeof (D) + 2 * sizeof (D::da[0])];
  p->da[0] = (char*)p->da - (char*)p;// -Wzero-length-bounds expected

  D d;
  p->da[1] = (char*)&d.b0i - (char*)&d;  // -Warray-bounds (good)

  return p;
}


;; Function f (_Z1fv, funcdef_no=1, decl_uid=2404, cgraph_uid=11,
symbol_order=10)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2
;; 2 succs { 1 }

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

_6 -> { _3 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 3
Number of blocks to update: 1 ( 33%)



Value ranges after VRP:

_3: void * [1B, +INF]
_6: struct D * [1B, +INF]  EQUIVALENCES: { _3 } (1 elements)


t.C: In function ‘void* f()’:
t.C:11:10: warning: array subscript 0 is outside array bounds of ‘int [0]’
[-Warray-bounds]
   11 |   p->da[0] = (char*)p->da - (char*)p;// -Wzero-length-bounds
expected
  |   ~~~^
t.C:6:28: note: while referencing ‘D::da’
6 | struct D: B1, B2 { int di, da[0]; };
  |^~
t.C:14:10: warning: array subscript 1 is outside array bounds of ‘int [0]’
[-Warray-bounds]
   14 |   p->da[1] = (char*)&d.b0i - (char*)&d;  // -Warray-bounds (good)
  |   ~~~^
t.C:6:28: note: while referencing ‘D::da’
6 | struct D: B1, B2 { int di, da[0]; };
  |^~
void * f ()
{
  struct D * _3;

   [local count: 1073741824]:
  _3 = operator new [] (32);
  _3->da[0] = 20;
  _3->da[1] = 20;
  return _3;

}

[Bug c++/99642] Compiler error while using precompiled header and -Wmismatched-tags flag

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-03-18
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The assert below fails:

  /* For implicit instantiations of a primary template look up
 the primary or partial specialization and use it as
 the expected class-key rather than using the class-key of
 the first reference to the instantiation.  The primary must
 be (and inevitably is) at index zero.  */
  tree spec = specialization_of (type);
  cdlguide = class2loc.get (spec);
  gcc_assert (cdlguide != NULL);

[Bug c++/99642] Compiler error while using precompiled header and -Wmismatched-tags flag

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0

--- Comment #2 from Martin Sebor  ---
Likely introduced in r279480 (GCC 10) when -Wmismatched-tags was added.  Not a
regression since the option is off by default.

[Bug tree-optimization/99502] missing -Warray-bounds on partial out of bounds access in C++

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |11.0
 Resolution|--- |FIXED

--- Comment #2 from Martin Sebor  ---
Fixed in r11-7724.

[Bug c++/99642] Compiler error while using precompiled header and -Wmismatched-tags flag

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Sebor  ---
Type and spec are the messages facet, but the same problem happens with other
types.  A simpler test case is:

$ (set -x && cat pch.h && cat main.cpp)
+ cat pch.h
#include 
+ cat main.cpp
#include 
#include "pch.h"
int main () {}

which aborts for basic_istream (and basic_ostream, but no other types).

The problem is that some of these types are added to class2loc mapping as they
should be, but with a different address than when they're looked up. 
Instrumenting the code to print out the tree node (as @%p) shows this.  The
address after type_decl, @0x7fdba48705f0, in the first message, doesn't match
the address after spec, @0x10001df1f0:

/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/iosfwd:83:11: note:
add: type_decl @0x7fdba48705f0: ‘class std::basic_istream<_CharT, _Traits>’,
exist: 0, def_p: 0, complete: 0, template_decl: 1
   83 | class basic_istream;
  |   ^
and then
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/iosfwd:83:11: note:
diag_mismatched_tags: type_decl: ‘class std::basic_istream<_CharT, _Traits>’
   83 | class basic_istream;
  |   ^
main.cpp:3:14: note: diag_mismatched_tags: type: ‘std::basic_istream<_CharT,
_Traits>’, spec @0x10001df1f0: ‘std::basic_istream<_CharT, _Traits>’
3 | int main () {}
  |  ^

A record of basic_istream exists but can't be looked up.

[Bug sanitizer/99673] [11 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||11.0
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org
   Last reconfirmed||2021-03-19
Summary|[11 Regression] bogus   |[11 Regression] bogus
   |-Wstringop-overread warning |-Wstringop-overread warning
   |with address sanitizer  |with address sanitizer due
   ||to member address
   ||substitution

--- Comment #1 from Martin Sebor  ---
A further reduced/simplified test case is below.  The root cause is similar to
the one discussed in pr99578 comment 8.

$ cat pr99673.c && gcc -Os -S -Wall -fsanitize=address
-fno-inline-functions-called-once -m32 pr99673.c
struct B {
  int i;
  struct A {
short sa[8];
  } a[2];
};

struct C {
  char n, ax[];
};

struct D { int i, j, k; };

int f (const short[8]);

void g (struct C *pc, struct D *pd, int i)
{
  struct B *pb = (void *)pc->ax;
  pd->i = pb->i;

  const short *psa = pb->a[i].sa;
  if (f (psa))
return;
}
pr99673.c: In function ‘g’:
pr99673.c:22:7: warning: ‘f’ reading 16 bytes from a region of size 4
[-Wstringop-overread]
   22 |   if (f (psa))
  |   ^~~
pr99673.c:22:7: note: referencing argument 1 of type ‘const short int *’
pr99673.c:14:5: note: in a call to function ‘f’
   14 | int f (const short[8]);
  | ^

The output of -fdump-tree-optimized shows what triggers the warning.  The
difference between the case discussed in pr99578 comment 8 and this is here
that it's the sanopt pass that replaces the pb->a[i].sa as the argument to f()
with the address of pc->i plus some offset.  pc->i is a 4-byte int, which is
where the 4 bytes in the warning comes from.

;; Function g (g, funcdef_no=0, decl_uid=2314, cgraph_uid=1, symbol_order=0)

void g (struct C * pc, struct D * pd, int i)
{
  const short int * psa;
  int _1;
  sizetype _9;
  sizetype _10;
  sizetype _11;
  unsigned int _12;
  int * _13;
  int * _14;
  unsigned int _17;
  unsigned int _18;
  signed char * _19;
  signed char _20;
  _Bool _21;
  unsigned int _22;
  signed char _23;
  signed char _24;
  _Bool _25;
  _Bool _26;
  unsigned int _27;
  unsigned int _28;
  unsigned int _29;
  signed char * _30;
  signed char _31;
  _Bool _32;
  unsigned int _33;
  signed char _34;
  signed char _35;
  _Bool _36;
  _Bool _37;

   [local count: 1073741824]:
  _13 = &MEM[(struct B *)pc_2(D) + 1B].i;   <<< address of pc.i
  _12 = (unsigned int) _13;
  _17 = _12 >> 3;
  _18 = _17 + 536870912;
  _19 = (signed char *) _18;
  _20 = *_19;
  _21 = _20 != 0;
  _22 = _12 & 7;
  _23 = (signed char) _22;
  _24 = _23 + 3;
  _25 = _24 >= _20;
  _26 = _21 & _25;
  if (_26 != 0)
goto ; [0.05%]
  else
goto ; [99.95%]

   [local count: 536864]:
  __builtin___asan_report_load4 (_12);

   [local count: 1073741824]:
  _1 = MEM[(struct B *)pc_2(D) + 1B].i;
  _14 = &pd_4(D)->i;
  _27 = (unsigned int) _14;
  _28 = _27 >> 3;
  _29 = _28 + 536870912;
  _30 = (signed char *) _29;
  _31 = *_30;
  _32 = _31 != 0;
  _33 = _27 & 7;
  _34 = (signed char) _33;
  _35 = _34 + 3;
  _36 = _35 >= _31;
  _37 = _32 & _36;
  if (_37 != 0)
goto ; [0.05%]
  else
goto ; [99.95%]

   [local count: 536864]:
  __builtin___asan_report_store4 (_27);

   [local count: 1073741824]:
  pd_4(D)->i = _1;
  _9 = (sizetype) i_6(D);
  _10 = _9 * 16;
  _11 = _10 + 4;
  psa_7 = _13 + _11;<<< &pc.i + (i * 16) + 4
  f (psa_7); [tail call]
  return;

}

The output below shows the difference between the last "good" IL and the "bad"
IL introduced by the sanopt transformation.  To avoid the warning either the
sanopt pass will need to be changed to avoid this substitution or to annotate
it somehow so the warning knows not to trigger.

--- pr99673.c.184t.slsr 2021-03-19 15:21:31.134229177 -0600
+++ pr99673.c.239t.sanopt   2021-03-19 15:21:31.135229188 -0600
@@ -1,13 +1,14 @@

 ;; Function g (g, funcdef_no=0, decl_uid=2314, cgraph_uid=1, symbol_order=0)

-;; 1 loops found
-;;
-;; Loop 0
-;;  header 0, latch 1
-;;  depth 0, outer -1
-;;  nodes: 0 1 2
-;; 2 succs { 1 }
+
+Symbols to be put in SSA form
+{ D.2322 }
+Incremental SSA update started at block: 0
+Number of blocks in CFG: 7
+Number of blocks to update: 6 ( 86%)
+
+
 void g (struct C * pc, struct D * pd, int i)
 {
   const short int * psa;
@@ -15,23 +16,81 @@
   sizetype _9;
   sizetype _10;
   sizetype _11;
-  struct B * _12;
+  unsigned int _12;
   int * _13;
   int * _14;
+  unsigned int _17;
+  unsigned int _18;
+  signed char * _19;
+  signed char _20;
+  _Bool _21;
+  unsigned int _22;
+  signed char _23;
+ 

[Bug middle-end/99676] New: missing detail in warning for passing smaller array to bigger argument

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99676
   Summary: missing detail in warning for passing smaller array to
bigger argument
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The warning(s) below are confusing:
1) each mentions the argument type is 'int *' when it actually uses 'int[4]' to
trigger, and
2) it doesn't point to the declaration of the object or subobject whose size it
uses.
In cases like pr99673 the missing details make the warning harder than
necessary to understand and decide if it's a false positive.

$ cat x.c && gcc -O -S -Wall x.c
struct A { int a[2], b[2]; };

void f (int[4], int[4]);

void g (int *p, int *q)
{
  f (p, q);
}

void h (struct A *p)
{
  g (p->a, p->b);
}
In function ‘g’,
inlined from ‘h’ at x.c:12:3:
x.c:7:3: warning: ‘f’ accessing 16 bytes in a region of size 8
[-Wstringop-overflow=]
7 |   f (p, q);
  |   ^~~~
x.c: In function ‘h’:
x.c:7:3: note: referencing argument 1 of type ‘int *’
In function ‘g’,
inlined from ‘h’ at x.c:12:3:
x.c:7:3: warning: ‘f’ accessing 16 bytes in a region of size 8
[-Wstringop-overflow=]
x.c: In function ‘h’:
x.c:7:3: note: referencing argument 2 of type ‘int *’
x.c:3:6: note: in a call to function ‘f’
3 | void f (int[4], int[4]);
  |  ^

[Bug middle-end/99676] missing detail in warning for passing smaller array to bigger argument

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Blocks||88443

--- Comment #1 from Martin Sebor  ---
The warning should also not be -Wstringop-overflow or -Wstringop-overread
(which are meant to be about accesses by functions declared in  and
maybe also direct string accesses by pointers) but probably -Warray-bounds.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug sanitizer/99673] [11 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Martin Sebor  ---
None of the -Wstringop-xxx warnings (either true or false positives) affects
code generation.

Thanks for the true vs false positive breakdown.  If you remember and could let
me know the details of the real bugs that'd be great.  (In addition to
reporting any false positives we don't yet know about as you have been.)

[Bug middle-end/99714] New: warn about alloca/dealloc mismatches based on calls with same object in different functions

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99714
   Summary: warn about alloca/dealloc mismatches based on calls
with same object in different functions
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Deallocating an object in one function through a pointer that's assigned the
result of a mismatched allocation in another function is almost certainly a
bug.  Diagnosing such mismatched calls would help detect at compile time
problems like pr99687 that are currently only detected by dynamic analysis
tools.

#if __cplusplus

struct A {
  int *p;
  A (int);
  ~A ();
};

A::A (int n): p (new int[n]{ }) { }

A::~A ()
{
  delete p;// missing -Wmismatched-new-delete
}
#else

struct A { int *p; };

void dealloc (void*);
__attribute__ ((malloc (dealloc))) void* alloc (int);

void init (struct A *p, int n) { p = alloc (n * sizeof *p); }
void fini (struct A *p)
{
  __builtin_free (p);  // missing -Wmismatched-dealloc
}

#endif

[Bug middle-end/99715] New: bogus/missing Wmismatched-dealloc warnings

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99715
   Summary: bogus/missing Wmismatched-dealloc warnings
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is a meta-bug to track false positives and negatives in the
-Wmismatched-dealloc warning, new in GCC 11.

[Bug middle-end/99714] warn about alloca/dealloc mismatches based on calls with same object in different functions

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||documentation
 Blocks||99715
   Severity|normal  |enhancement


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99715
[Bug 99715] [meta-bug] bogus/missing Wmismatched-dealloc warnings

[Bug middle-end/99715] [meta-bug] bogus/missing Wmismatched-dealloc warnings

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug middle-end/99714] warn about alloca/dealloc mismatches based on calls with same object in different functions

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|dmalcolm at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
  Component|analyzer|middle-end
   Keywords|documentation   |diagnostic

--- Comment #2 from Martin Sebor  ---
The C test case (corrected below) is meant to allocate and deallocate the the
member pointer, just like the C++ test case.

I also raise this as an enhancement for the -Wmismatched-dealloc and
Wmismatched-new-delete warnings (hence Changing component back to middle-end),
although I think it would be worthwhile improvement to the analyzer as well. 
I'm not sure what the best way is to track enhancements to both kinds of
warnings.  Clone one to the other?

struct A { int *p; };

void dealloc (void*);
__attribute__ ((malloc (dealloc))) void* alloc (int);

void init (struct A *p, int n) { p->p = alloc (n * sizeof *p); }
void fini (struct A *p)
{
  __builtin_free (p->p);  // missing -Wmismatched-dealloc
}

#endif

[Bug tree-optimization/99739] New: [11 Regression] missing optimization of a repeated conditional

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99739
   Summary: [11 Regression] missing optimization of a repeated
conditional
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Prior to r11-5805 both ff() and gg() in the test case below resulted in optimal
code.  With the change, the second conditional in g() is no longer recognized
as equivalent to the first and so the function isn't optimized as expected.

Incidentally, the same regression was also introduced once before: in r235653.

$ cat x.c && gcc -O1 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
static inline int f (int i, int j, int k)
{
  int x = 1;

  if (i && j && k)
x = 2;

  if (i && j && k)
return x;

  return -1;
}

void ff (int i, int j, int k)
{
  int x = f (i, j, k);
  if (x == 1)
__builtin_abort ();
}


static inline int g (int i, int j, int k)
{
  int x = 1;

  if (i && j && k)
x = 2;

  if (i && k && j)
return x;

  return -1;
}

void gg (int i, int j, int k)
{
  int x = g (i, j, k);
  if (x == 1)
__builtin_abort ();
}

;; Function ff (ff, funcdef_no=1, decl_uid=1951, cgraph_uid=2, symbol_order=1)

void ff (int i, int j, int k)
{
   [local count: 1073741824]:
  return;

}



;; Function gg (gg, funcdef_no=3, decl_uid=1963, cgraph_uid=4, symbol_order=3)

Removing basic block 6
Removing basic block 7
void gg (int i, int j, int k)
{
  _Bool _7;
  _Bool _8;
  _Bool _11;
  _Bool _14;
  _Bool _16;

   [local count: 1073741824]:
  _7 = i_2(D) != 0;
  _8 = j_3(D) != 0;
  _14 = k_4(D) != 0;
  _11 = _7 & _14;
  _16 = _8 & _11;
  if (_16 != 0)
goto ; [94.27%]
  else
goto ; [5.73%]

   [local count: 1012175616]:
  if (k_4(D) != 0)
goto ; [100.00%]
  else
goto ; [0.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}

[Bug tree-optimization/99755] New: failure to fold a conditional that's a subset of another expression

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99755
   Summary: failure to fold a conditional that's a subset of
another expression
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC successfully folds to false the second conditional expression in f1() but
it fails to do the same in f2() and f3().  In addition (and likely as a
result), it triggers a bogus -Wmaybe-uninitialized in both functions. 

Clang and ICC fold all three expressions to false and emit optimal code for all
three functions.

Initializing the local variable to any value lets GCC fold the conditional and
avoid the warning.  But then, replacing  the test for x != i + 1 in f3() with x
!= 3 as shown at below the first test case, the conditional is again not folded
 (making the same change in f2() allows the folding to take place).

The bogus -Wmaybe-uninitialized first appeared in 4.9.  As far as I can tell
none of the failures to fold is a regression.

$ cat t.c && gcc -O2 -S -Wall t.c
void f1 (int i)
{ 
  int x;
  if (i > 1)
x = i + 1;

  if (i == 2 && x != i + 1)   // folded to false
__builtin_abort ();
}

void f2 (int i, int j)
{ 
  int x;
  if (i > 1 && j > 2)
x = i + 1;

  if (i == 2 && j == 3 && x != i + 1)   // not folded
__builtin_abort ();
}


void f3 (int i, int j, int k)
{
  int x;
  if (i > 1 && j > 2 && k > 3)
x = i + 1;

  if (i == 2 && j == 3 && k == 4 && x != i + 1)   // not folded
__builtin_abort ();
}


;; Function f1 (f1, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)

void f1 (int i)
{
   [local count: 1073741824]:
  return;

}
t.c: In function ‘f2’:
t.c:17:24: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   17 |   if (i == 2 && j == 3 && x != i + 1)
  |   ~^
t.c: In function ‘f3’:
t.c:28:34: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   28 |   if (i == 2 && j == 3 && k == 4 && x != i + 1)
  |   ~~~^


The following is also not folded:

void f3 (int i, int j, int k)
{ 
  int x = 0;
  if (i > 1 && j > 2 && k > 3)
x = i + 1;

  if (i == 2 && j == 3 && k == 4 && x != 3)   // not folded
__builtin_abort ();
}

[Bug tree-optimization/99756] New: bogus -Wmaybe-uninitialized with a use conditional that's a subset of a defining conditional

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 99756
   Summary: bogus -Wmaybe-uninitialized with a use conditional
that's a subset of a defining conditional
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The following code triggers a spurious -Wmaybe-uninitialized.  There are two
underlying problems: one is a limitation of the uninitialized pass and another
is a missed optimization opportunity described in PR 99755 (the second test for
k results in another read from it instead of reusing the value read previously
in the first conditional).

$ cat t.c && gcc -O2 -S -Wall t.c
extern int a[], i, j, k;

void f (void)
{
  int x;
  if (i > 1 && j > 2 && k > 3)
x = i + 1;

  if (i == 2 && j == 3 && k == 4)
a[x] = 0; // { dg-bogus "Wmaybe-uninitialized" }
}

t.c: In function ‘f3’:
t.c:28:10: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   28 | a[x] = 0; // { dg-bogus "Wmaybe-uninitialized" }
  | ~^~~

[Bug tree-optimization/99756] bogus -Wmaybe-uninitialized with a use conditional that's a subset of a defining conditional

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Depends on||99755
 Blocks||24639
  Known to fail||10.2.0, 11.0, 4.1.0, 4.8.4,
   ||4.9.4, 5.5.0, 6.4.0, 7.2.0,
   ||8.3.0, 9.1.0

--- Comment #1 from Martin Sebor  ---
The spurious warning goes as far back as GCC 4.1.  It can be avoided either by
improving the optimization or by changing tree-ssa-uninit.c.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99755
[Bug 99755] failure to fold a conditional that's a subset of another expression

[Bug middle-end/99768] [11 Regression] Bogus -Wuninitialized diagnostic with type punning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-25
 Status|UNCONFIRMED |NEW
  Component|c   |middle-end
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor  ---
The -Wuninitialized was introduced in
g:b825a22890740f341eae566af27e18e528cd29a7.  I don't think I meant for this to
be diagnosed so I suspect it's a bug in the new code.  I see no basis in the IL
(below) to issue the warning.  GCC should issue -Wstrict-aliasing instead (it
does but only at level 2).

float foo (unsigned int v)
{
  float * f;
  unsigned int tmp;
  float _5;

   :
  tmp = v_2(D);
  f_4 = &tmp;
  _5 = *f_4;<< -Wuninitialized
  tmp ={v} {CLOBBER};
  return _5;

}

[Bug tree-optimization/33802] bogus "is used uninitialized" (VOPs) (inlining)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org

--- Comment #15 from Martin Sebor  ---
The original test cases don't compile for me and I don't see the warning for
the test case in comment 13 with recent GCC (6 through 11).  I'm having trouble
pinpointing when it disappeared.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 33802, which changed state.

Bug 33802 Summary: bogus "is used uninitialized" (VOPs) (inlining)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33802

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug fortran/31279] Uninitialized warning for call-by-reference arguments with known intent(in)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|middle-end  |fortran

--- Comment #7 from Martin Sebor  ---
GCC added the attributes mentioned in comment #4 under the name access -- see
below.  Getting the middle end to issue a warning for the cases described in
comment #0 should be a matter of the Fortran front end making use of the
attribute.

$ cat x.c && gcc -S -Wall x.c
__attribute__ ((access (read_only, 1))) void f (int*);

void g (void)
{
  int x;
  f (&x);
}
x.c: In function ‘g’:
x.c:6:3: warning: ‘x’ is used uninitialized [-Wuninitialized]
6 |   f (&x);
  |   ^~
x.c:1:46: note: in a call to ‘f’ declared with attribute ‘access (read_only,
1)’ here
1 | __attribute__ ((access (read_only, 1))) void f (int*);
  |  ^
x.c:5:7: note: ‘x’ declared here
5 |   int x;
  |   ^

[Bug middle-end/36823] missing uninitialized warning (IPA, inlining)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Martin Sebor  ---
Bisection shows the -Wuninitialized at -O2 disappeared between r176911 and
r176920.  The likely candidate is r176918.

[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2019-02-24 00:00:00 |2021-3-25
  Known to fail|9.0 |10.2.0, 11.0, 9.3.0

--- Comment #13 from Martin Sebor  ---
I think the reason why the location for the last PHI argument isn't set is
because the argument is itself a PHI whose arguments have different locations:

   [local count: 1073741824]:
  # _16 = PHI <[pr40635.c:21:20] -1(13), [pr40635.c:19:15] s42_9(7),
[pr40635.c:28:16] -1(15), s42_21(9)>
  [pr40635.c:37:5] foo ();
  [pr40635.c:38:8] _28 = _16 < 0;
  [pr40635.c:38:8] _5 = (int) _28;
  [pr40635.c:38:8] _4 = -_5;
  return _4;

   [local count: 39298952]:

   [local count: 383953502]:
  # s42_21 = PHI <[pr40635.c:13:9] s42_18(D)(12), [pr40635.c:19:15] s42_9(14)>
  goto ; [100.00%]

}

Even if -Wuninitialized is changed to extract the location from the
uninitialized argument to s42_21(9), it doesn't use it because it prefers to
use the location of the statement where the variable us used.  -Wuninitialized
usually prints a note pointing to the uninitialized variable but it has the
code below that guards is:

  if (xloc.file != floc.file
  || linemap_location_before_p (line_table, location, cfun_loc)
  || linemap_location_before_p (line_table, cfun->function_end_locus,
location))
inform (DECL_SOURCE_LOCATION (var), "%qD was declared here", var);

Because the location of the variable is in a different function than the
current one the note isn't printed.  The patch below removes this IMO pointless
test and improves the output a bit:

pr40635.c:38:8: warning: ‘s42’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   38 | if (sockt_rd < 0)
  |^
pr40635.c:13:9: note: ‘s42’ was declared here
   13 | int s42, x;
  | ^~~

diff --git a/gcc/tree-ssa-uninit.c b/gcc/tree-ssa-uninit.c
index 0800f596ab1..a578a596fee 100644
--- a/gcc/tree-ssa-uninit.c
+++ b/gcc/tree-ssa-uninit.c
@@ -126,8 +126,6 @@ warn_uninit (enum opt_code wc, tree t, tree expr, tree var,
 const char *gmsgid, void *data, location_t phiarg_loc)
 {
   gimple *context = (gimple *) data;
-  location_t location, cfun_loc;
-  expanded_location xloc, floc;

   /* Ignore COMPLEX_EXPR as initializing only a part of a complex
  turns in a COMPLEX_EXPR with the not initialized part being
@@ -170,6 +168,7 @@ warn_uninit (enum opt_code wc, tree t, tree expr, tree var,
   || TREE_NO_WARNING (expr))
 return;

+  location_t location;
   if (context != NULL && gimple_has_location (context))
 location = gimple_location (context);
   else if (phiarg_loc != UNKNOWN_LOCATION)
@@ -178,9 +177,7 @@ warn_uninit (enum opt_code wc, tree t, tree expr, tree var,
 location = DECL_SOURCE_LOCATION (var);
   location = linemap_resolve_location (line_table, location,
   LRK_SPELLING_LOCATION, NULL);
-  cfun_loc = DECL_SOURCE_LOCATION (cfun->decl);
-  xloc = expand_location (location);
-  floc = expand_location (cfun_loc);
+
   auto_diagnostic_group d;
   if (warning_at (location, wc, gmsgid, expr))
 {
@@ -188,11 +185,7 @@ warn_uninit (enum opt_code wc, tree t, tree expr, tree
var,

   if (location == DECL_SOURCE_LOCATION (var))
return;
-  if (xloc.file != floc.file
- || linemap_location_before_p (line_table, location, cfun_loc)
- || linemap_location_before_p (line_table, cfun->function_end_locus,
-   location))
-   inform (DECL_SOURCE_LOCATION (var), "%qD was declared here", var);
+  inform (DECL_SOURCE_LOCATION (var), "%qD was declared here", var);
 }
 }

[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #14 from Martin Sebor  ---
Let me handle this for GCC 12.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 44547, which changed state.

Bug 44547 Summary: -Wuninitialized reports false warning in nested switch 
statements (missed switch optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44547

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/44547] -Wuninitialized reports false warning in nested switch statements (missed switch optimization)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #6 from Martin Sebor  ---
The warning is no longer issued.  Bisection points to r189173 as the "fix" at
-O2 and to r260350 as the revision when it stopped being issued at -O1.  Let me
add the test and resolve this as fixed.

[Bug tree-optimization/48483] Construct from yourself w/o warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||10.2.0, 11.0, 5.1.0
 Status|NEW |RESOLVED
  Component|c++ |tree-optimization
 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org

--- Comment #22 from Martin Sebor  ---
GCC diagnoses the test case in comment #0 at -O0 (one warning) as well as above
(two warnings) since r209443:

pr48483.C: In function ‘int main()’:
pr48483.C:12:22: warning: ‘a.A::b’ is used uninitialized [-Wuninitialized]
   12 | A   a(a.b);
  |  ^
pr48483.C:12:17: note: ‘a’ declared here
   12 | A   a(a.b);
  | ^

With -O1 and higher it also diagnoses the test case in comment #2:

In member function ‘int A::TheInt()’,
inlined from ‘int main()’ at pr48483-c2.C:11:16:
pr48483-c2.C:6:33: warning: ‘a.A::a’ is used uninitialized [-Wuninitialized]
6 | int TheInt(){return a;}
  | ^
pr48483-c2.C: In function ‘int main()’:
pr48483-c2.C:11:17: note: ‘a’ declared here
   11 | A   a(a.TheInt());
  | ^

At -O0 and above it also diagnoses the test case in comment #3 (also since
r209443)

pr48483-c3.C:5:12: warning: ‘s.main()::S::a’ is used uninitialized
[-Wuninitialized]
5 |   return s.a;
  |^
pr48483-c3.C:4:23: note: ‘s’ declared here
4 |   struct S { int a; } s;
  |   ^

The test case in comment #16 isn't diagnosed but that one is sufficiently
different that I think it should be tracked separately (if it isn't yet; I
suspect there probably is a duplicate somewhere but if not I'll add one).

With that, let me add the passing test cases and resolve this as fixed.

[Bug c++/52167] self-initialization should at least produce use-of-uninitialized warning

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52167
Bug 52167 depends on bug 48483, which changed state.

Bug 48483 Summary: Construct from yourself w/o warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48483

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/52167] self-initialization should at least produce use-of-uninitialized warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to fail||10.2.0, 4.1.0, 4.8.4,
   ||4.9.4, 5.5.0, 6.4.0, 7.2.0,
   ||8.3.0, 9.1.0
   Target Milestone|--- |11.0
 Status|NEW |RESOLVED
  Component|c++ |tree-optimization

--- Comment #8 from Martin Sebor  ---
GCC 11 (since g:b825a22890740f341eae566af27e18e528cd29a7) diagnoses passing an
uninitialized object by const reference by -Wmaybe-uninitialized:

$ g++ -S -Wall pr52167.C
pr52167.C: In function ‘int main()’:
pr52167.C:8:23: warning: ‘foo’ may be used uninitialized
[-Wmaybe-uninitialized]
8 |   const string foo(foo);
  |   ^
In file included from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/string:55,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/locale_classes.h:40,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ios_base.h:41,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/ios:42,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/ostream:38,
 from
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/iostream:39,
 from pr52167.C:1:
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:448:7:
note: by argument 2 of type ‘const std::__cxx11::basic_string&’ to
‘std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::basic_string(const
std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&) [with _CharT = char;
_Traits = std::char_traits; _Alloc = std::allocator]’ declared here
  448 |   basic_string(const basic_string& __str)
  |   ^~~~
pr52167.C:8:16: note: ‘foo’ declared here
8 |   const string foo(foo);
  |^~~

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 52167, which changed state.

Bug 52167 Summary: self-initialization should at least produce 
use-of-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52167

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/52523] Missing "uninitialized" warning (VOP, taking address of var)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED
   Keywords||diagnostic
 Resolution|--- |FIXED
   Target Milestone|--- |11.0
  Known to fail||10.2.0, 4.7.0, 4.8.4,
   ||4.9.4, 5.5.0, 6.4.0, 7.2.0,
   ||8.3.0, 9.1.0

--- Comment #2 from Martin Sebor  ---
GCC 11 (since g:b825a22890740f341eae566af27e18e528cd29a7) diagnoses passing an
uninitialized object by const reference by -Wmaybe-uninitialized:

$ g++ -S -Wall pr52523.C
pr52523.C: In function ‘int main()’:
pr52523.C:6:13: warning: ‘x’ is used uninitialized [-Wuninitialized]
6 |   std::cout << x;
  |   ~~^~~~
pr52523.C:5:7: note: ‘x’ declared here
5 |   int x;
  |   ^

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 52523, which changed state.

Bug 52523 Summary: Missing "uninitialized" warning (VOP, taking address of var)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52523

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/40635] bogus name and location in 'may be used uninitialized' warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||pa...@matos-sorge.com

--- Comment #15 from Martin Sebor  ---
*** Bug 53917 has been marked as a duplicate of this bug. ***

[Bug middle-end/53917] Wuninitialized warning points to place where variable doesn't occur

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #8 from Martin Sebor  ---
The underlying problem with the test case in comment #1 is the same as the one
discussed in bug 40635 comment #13.  With the patch there applied, GCC issues a
note after the warning that points to the uninitialized variable:

pr53917-c1.c: In function ‘fn4’:
pr53917-c1.c:38:8: warning: ‘valid’ may be used uninitialized
[-Wmaybe-uninitialized]
   38 | if (fn3 (&p_t1_rw_fsm_data.tag_mem_config))
  |^
pr53917-c1.c:25:9: note: ‘valid’ was declared here
   25 | int valid;
  | ^

There may be more that can be done to improve the context of the warning to
make it clearer but we can track those improvements separately.

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 53917, which changed state.

Bug 53917 Summary: Wuninitialized warning points to place where variable 
doesn't occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/83336] [meta-bug] Issues with displaying inlining chain for middle-end warnings

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83336
Bug 83336 depends on bug 53917, which changed state.

Bug 53917 Summary: Wuninitialized warning points to place where variable 
doesn't occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53917

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 54804, which changed state.

Bug 54804 Summary: -Wuninitialized fails to warn about uninitialized local union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54804

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/54804] -Wuninitialized fails to warn about uninitialized local union

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |7.0
   Keywords||diagnostic

--- Comment #2 from Martin Sebor  ---
GCC 7 and later warn for both.  The change was introduced in r245840.

pr54804.c: In function ‘yyparse’:
pr54804.c:7:13: warning: ‘yylval’ is used uninitialized [-Wuninitialized]
7 |  return yylval;
  | ^~
pr54804.c:6:20: note: ‘yylval’ declared here
6 |  union YYSTYPE yylval;
  |^~
pr54804.c: In function ‘yyparse_with_struct’:
pr54804.c:16:13: warning: ‘xxlval’ is used uninitialized [-Wuninitialized]
   16 |  return xxlval;
  | ^~
pr54804.c:15:15: note: ‘xxlval’ declared here
   15 |  struct s xxlval;
  |   ^~

[Bug tree-optimization/55060] False un-initialized variable warnings (fixed, add testcase to testsuite)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||msebor at gcc dot gnu.org
   Target Milestone|--- |5.0

--- Comment #7 from Martin Sebor  ---
Bisection points to r217125 as the fix.  Let me add the test and resolve it.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 55060, which changed state.

Bug 55060 Summary: False un-initialized variable warnings (fixed, add testcase 
to testsuite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55060

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug tree-optimization/55288] Improve handling/suppression of maybe-uninitialized warnings

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0
 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
The false positive was fixed in r202496.  Let me add the test.  

Clang implements attribute uninitialized (with slightly different meaning than
what's being requested here) so adding support for it to GCC to help control
warnings might make sense:
https://clang.llvm.org/docs/AttributeReference.html#uninitialized

gcc-bugs@gcc.gnu.org

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Known to fail||10.2.0, 11.0, 4.7.4, 4.8.4,
   ||4.9.4, 5.5.0, 6.4.0, 7.2.0,
   ||8.3.0, 9.1.0
 CC||msebor at gcc dot gnu.org
   Last reconfirmed|2013-03-11 00:00:00 |2021-3-26

--- Comment #12 from Martin Sebor  ---
Reconfirming for GCC 11.

With a slightly tweaked test case and a patched GCC to print the conditions
under which it determines the variable is uninitialized the note after the
warning makes it clear even without looking at the dump that the warning is a
false positive.

$ cat pr56574.c && gcc -O2 -S -Wuninitialized -Wmaybe-uninitialized
-fdump-tree-uninit=/dev/stdout pr56574.c
int f (void);

void g (int i)
{
  int x;

  if (i == 0)
x = f ();

  for (;;)
{
if (i == 0 && x)
  continue;

if (i == 0)
  break;
  }
}

;; Function g (g, funcdef_no=0, decl_uid=1945, cgraph_uid=1, symbol_order=0)

0 dep_chains for phi_bb 4, use_bb 4:
tmp chain = i_6(D) == 0
one_pred = i_6(D) == 0
pr56574.c: In function ‘g’:
pr56574.c:12:16: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   12 | if (i == 0 && x)
  |^~
pr56574.c:5:7: note: when ‘i != 0’
5 |   int x;
  |   ^
pr56574.c:5:7: note: ‘x’ was declared here
void g (int i)
{
  int x;
  _Bool _14;
  _Bool _15;
  _Bool _16;

   [local count: 79134772]:
  if (i_6(D) == 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 53020297]:
  goto ; [100.00%]

   [local count: 26114475]:
  x_10 = f ();

   [local count: 79134772]:
  # x_11 = PHI 
  _14 = i_6(D) == 0;
  _15 = x_11 != 0;
  _16 = _14 & _15;

   [local count: 719407024]:

   [local count: 1073741824]:
  if (_16 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 354334800]:
  goto ; [100.00%]

   [local count: 719407024]:
  if (i_6(D) == 0)
goto ; [11.00%]
  else
goto ; [89.00%]

   [local count: 640272252]:
  goto ; [100.00%]

   [local count: 79134772]:
  return;

}

[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
   Last reconfirmed|2014-09-12 00:00:00 |2021-3-26
  Known to fail||10.2.0, 11.0, 4.9.3, 5.3.0,
   ||6.2.0, 7.5.0, 8.3.0, 9.3.0
 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
Reconfirming with GCC 11.

[Bug fortran/56670] Allocatable-length character var causes bogus warning with -Wuninitialized

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||10.2.0, 11.0, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.3.0,
   ||9.1.0
   Last reconfirmed|2014-03-22 00:00:00 |2021-3-26
 CC||msebor at gcc dot gnu.org

--- Comment #10 from Martin Sebor  ---
Reconfirming with GCC 11.

[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2018-10-09 00:00:00 |2021-3-26
  Known to fail||10.2.0, 11.0, 4.8.4, 4.9.4,
   ||5.5.0, 6.4.0, 7.2.0, 8.3.0,
   ||9.1.0
 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
Reconfirmed with GCC 11 and a slightly further reduced test case:

int a, b, d;

void f (void)
{
  unsigned c;

  for (int e = 0; e < 64; e += 6)
{
  if (e)
b = e;
  else
c = d;

  if (e)
a += c;
}
}

The output with a slightly patched GCC to add notes after the warning shows the
condition under which the variable is used uninitialized:

pr57832.c: In function ‘f’:
pr57832.c:15:11: warning: ‘c’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   15 | a += c;
  |   ^~
pr57832.c:5:12: note: used when ‘ivtmp != 0’
5 |   unsigned c;
  |^
pr57832.c:5:12: note: ‘c’ was declared here


The annotated dump below helps explain what's going on: the c_21 PHI in bb 3 is
(partly) uninitialized.  The warning finds its first use (1) in c_21 in bb 3. 
It then finds its use (2) in c_25 in bb 5.  Finally, it finds c_25's use (3) in
the assignment to _4 in bb 4.  In other words, the uninitialized c flows from
 ->  ->  ->  ->  -> .  I don't see anything in the IL to avoid coming to this conclusion so I
don't think there's anything to change in the warning code to suppress it.


;; Function f (f, funcdef_no=0, decl_uid=1946, cgraph_uid=1, symbol_order=3)

[WORKLIST]: add to initial list: c_21 = PHI 
[CHECK]: examining phi: c_21 = PHI 

[CHECK] Found def edge 1 in c_25 = PHI 
[CHECK]: Found unguarded use: c_25 = PHI 
[WORKLIST]: Update worklist with phi: c_25 = PHI 

[CHECK] Found def edge 1 in c_25 = PHI 
[CHECK]: Found unguarded use: _4 = a.2_3 + c_21;

{
  unsigned int ivtmp.11;
  unsigned int ivtmp.10;
  int a_lsm.7;
  int b_lsm.6;
  int e;
  unsigned int c;
  int d.0_1;
  unsigned int a.2_3;
  unsigned int _4;
  int _5;

   [local count: 89442694]:
  d.0_1 = d;
  c_14 = (unsigned int) d.0_1;
  a_lsm.7_18 = a;

   [local count: 984299128]:
  # c_21 = PHI<<< use 1: c_12(D) is
uninitialized
  # a_lsm.7_11 = PHI 
  # ivtmp.10_2 = PHI 
  # ivtmp.11_20 = PHI 
  e_22 = (int) ivtmp.10_2;
  if (e_22 != 0)
goto ; [64.00%]
  else
goto ; [36.00%]

   [local count: 354347685]:
  goto ; [100.00%]

   [local count: 629951444]:
  a.2_3 = (unsigned int) a_lsm.7_11;
  _4 = a.2_3 + c_21;   <<< use 3:
-Wmaybe-uninitialized
  _5 = (int) _4;
  e_17 = (int) ivtmp.11_20;
  if (e_17 <= 63)
goto ; [86.98%]
  else
goto ; [13.02%]

   [local count: 547959327]: <<< c_21(8) = c21(3)

   [local count: 902307011]:
  # c_25 = PHI   <<< use 2: c_25 =
c_21(8)
  # a_lsm.7_10 = PHI <_5(8), a_lsm.7_11(7)>
  ivtmp.10_7 = ivtmp.10_2 + 6;
  ivtmp.11_26 = ivtmp.11_20 + 6;
  goto ; [100.00%]

   [local count: 89442696]:
  b = e_22;
  a = _5;
  return;

}

[Bug tree-optimization/59970] Bogus Wuninitialized warnings at low optimization levels

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
 CC||msebor at gcc dot gnu.org
  Known to fail||4.8.4, 4.9.4, 5.5.0, 6.4.0
   Keywords||diagnostic
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Martin Sebor  ---
The test case in comment #0 is not diagnosed anymore.  Bisection points to
r240221 as the fix.  Ditto for attachment 35384 from comment #3.  Let me add
the one from attachment 31970 to the test suite and resolve this as fixed.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 59970, which changed state.

Bug 59970 Summary: Bogus Wuninitialized warnings at low optimization levels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59970

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2016-08-23 00:00:00 |2021-3-26
  Known to fail|7.0 |11.0

--- Comment #6 from Martin Sebor  ---
Reconfirming with GCC 11.

The problem is that when the address of a variable escapes, because GCC doesn't
track when, when the function from which it escapes calls another that might
access the escaped variable, the warning (as a result of relying on the
conservative assumptions the optimizers must make) assumes the called function
initializes the variable.  Another example of this is function h() below.

The irony (and I'd say the bug) here is that the warning uses the same
conservative assumptions to trigger in cases when an equivalent same situation
might lead to the variable not having been initialized such as in g() below. 
These conflicting assumptions make the warning seem unpredictable.

$ cat z.c && gcc -O2 -S -Wall z.c
void f (void);

int i, *p;

int g (int j)
{
  int x;
  if (i)   // assume i is zero
x = j + 1;

  f ();// assume call sets i

  if (i)
return x;  // issue -Wmaybe-uninitalized

  return i;
}

int h (int j)
{
  int x;

  p = &x;  // address of x escapes

  f ();// assume call sets x

  return x;// avoid warning here
}

z.c: In function ‘g’:
z.c:14:12: warning: ‘x’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   14 | return x;  // issue -Wmaybe-uninitalized
  |^
z.c:7:7: note: ‘x’ was declared here
7 |   int x;
  |   ^

[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from Martin Sebor  ---
In the reduced test cases (in comment #3 and comment #4) d is a global variable
so it's value is zero.  c is assigned in the first iteration of the loop (when
e is zero) and used in subsequent iterations when it has a defined value, so
the warning .seems like a clear false postive to me.  (I didn't look at the big
test case.)

[Bug tree-optimization/43361] missing uninitialized warning without optimization (-O0) (PHI in always_executed basic block)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2010-03-14 15:45:50 |2021-3-29

--- Comment #14 from Martin Sebor  ---
Reconfirmed with GCC 11 and the C test case below:

void f (int);

int main () {
int i;
int array[10];
for (; i<10; ++i) { // no warning
f (i);  // no warning
array [i] = i;  // no warning, really hurts
}
}

[Bug middle-end/60488] missing uninitialized warning (address taken, VOP)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from Martin Sebor  ---
You're right, the test cases aren't equivalent, or meant to be.  What I want to
highlight is that in the test case in comment #6, in g() and other similar ones
like it the warning is most likely going to be a false positive, while in h(),
not warning most likely a false negative.  Both of these "problems" are due to
the same underlying assumption: that a variable whose address escapes may be
modified by a subsequent call to an unknown function.

The upshot is that the warning (indeed, all flow-based warnings) should
consider not just what can be proven might happen based on the IL but also the
likelihood with which it might happen.  I'm not saying there's a coding bug in
the implementation of the warning, rather that the heuristics it implements
aren't sufficient to capture this distinction.

[Bug middle-end/61112] Simple example triggers false-positive -Wmaybe-uninitialized warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99756
   Last reconfirmed|2019-03-03 00:00:00 |2021-3-29
  Known to work|6.1.0   |
  Known to fail||10.2.0, 11.0, 4.9.4, 5.5.0,
   ||6.4.0, 7.2.0, 8.3.0, 9.1.0

--- Comment #8 from Martin Sebor  ---
I've added both the passing test case from comment #0 and the still failing
test case from comment #5 to the test suite and xfailed the latter (thus
reconfirming for GCC 11).  Without any further analysis, the comment #5 test
case also looks similar to pr99756.

[Bug middle-end/61428] wrong "maybe-uninitialized" (jump threading? predicate analysis?)

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |8.0
 Status|NEW |RESOLVED
  Known to fail||5.5.0, 6.4.0, 7.2.0
 CC||msebor at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
Fixed by r256320.

[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794
Bug 19794 depends on bug 61428, which changed state.

Bug 61428 Summary: wrong "maybe-uninitialized" (jump threading? predicate 
analysis?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61428

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED