[Bug middle-end/108154] Inappropriate -Wstringop-overread in the C99 [static n] func param decl

2022-12-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108154

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Martin Sebor  ---
The warning here is intentional -- as noted, a [static 1] array can be as small
as a single element.  The warning is designed to help detect stronger
assumptions inadvertently made by the function definition.  (The compiler makes
no analysis to see how the function is being called; it could if the function
were declared static but but without full LTO it can't for an extern function.)

The recommended annotation to indicate that a pointer argument must not be null
is attribute nonnull.

[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings

2022-12-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
Bug 97048 depends on bug 108154, which changed state.

Bug 108154 Summary: Inappropriate -Wstringop-overread in the C99 [static n] 
func param decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108154

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

2022-09-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 107069, which changed state.

Bug 107069 Summary: string assignment triggers warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107069

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6

2022-09-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329

Martin Sebor  changed:

   What|Removed |Added

 CC||joerg.rich...@pdv-fs.de

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

[Bug c++/107069] string assignment triggers warning

2022-09-29 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107069

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2022-9-29
 Resolution|--- |DUPLICATE
  Known to work||13.0
  Known to fail||12.2.0

--- Comment #2 from Martin Sebor  ---
The warning doesn't show up on trunk (GCC 13) with the fix in r13-2618 so let's
mark it a duplicate of pr105329.

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

[Bug tree-optimization/107038] [13 Regression] Bogus -Wstringop-overflow= since r13-2789-gb40b3035879cf695

2022-09-26 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107038

--- Comment #3 from Martin Sebor  ---
Just a quick note from what I see in GDB.  The warning is issued by the 2nd run
of the waccess pass (-fdump-tree-waccess2) for the following statement in bb 22
in pread():

  iftmp.21_88 = __pread_alias (_50, _82, _81, _79);

_81's range reported by range_query::range_of_expr (vr, exp, stmt) is [58,
ULONG_MAX], matching the range in the warning.

A partial output of debug_ranger() for the function is below.  I must be
reading it wrong because  I don't see what the range above is derived from.

=== BB 19 
Imports: recvd_78  _83  
Exports: _51  recvd_78  recvd.17_80  _83  _94  _116  _125  
_83 [irange] UNDEFINED
 [local count: 169058114]:
if (_83 == 18446744073709551615)
  goto ; [34.00%]
else
  goto ; [66.00%]

19->22  (T) _83 :   [irange] UNDEFINED
19->20  (F) _83 :   [irange] UNDEFINED

=== BB 20 
Imports: _81  _83  
Exports: _81  _83  _85  _86  _87  
 _85 : _81(I)  _83(I)  
 _86 : _81(I)  _83(I)  _85  
 _87 : _81(I)  _83(I)  _85  _86  
_81 [irange] long unsigned int VARYING
_83 [irange] long unsigned int VARYING
 [local count: 280636469]:
_85 = _81 <= _83;
_86 = (int) _85;
_87 = __builtin_constant_p (_86);
if (_87 != 0)
  goto ; [50.00%]
else
  goto ; [50.00%]

_86 : [irange] int [0, 1] NONZERO 0x1
_87 : [irange] int [0, 0] NONZERO 0x0
20->21  (T) _81 :   [irange] UNDEFINED
20->21  (T) _83 :   [irange] UNDEFINED
20->21  (T) _85 :   [irange] UNDEFINED
20->21  (T) _86 :   [irange] UNDEFINED
20->21  (T) _87 :   [irange] UNDEFINED
20->24  (F) _86 :   [irange] int [0, 1] NONZERO 0x1
20->24  (F) _87 :   [irange] int [0, 0] NONZERO 0x0

=== BB 21 
Imports: recvd_78  _81  _83  
Exports: _51  recvd_78  recvd.17_80  _81  _83  _94  _116  _125  
_81 [irange] UNDEFINED
_83 [irange] UNDEFINED
 [local count: 140318235]:
if (_81 <= _83)
  goto ; [50.00%]
else
  goto ; [50.00%]

21->22  (T) _81 :   [irange] UNDEFINED
21->22  (T) _83 :   [irange] UNDEFINED
21->23  (F) _81 :   [irange] UNDEFINED
21->23  (F) _83 :   [irange] UNDEFINED

=== BB 22 
 [local count: 127638877]:
iftmp.21_88 = __pread_alias (_50, _82, _81, _79);
goto ; [100.00%]

[Bug c/106988] subscripting a string literal is not an integer constant expression but __builtin_strlen is

2022-09-22 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106988

Martin Sebor  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |---
 Status|RESOLVED|UNCONFIRMED
   Keywords|diagnostic  |rejects-valid

--- Comment #2 from Martin Sebor  ---
After experimenting with this some more I think the decision to reject this and
the other similar requests should be reconsidered.  GCC accepts many equivalent
nonconstant expressions in contexts where they are required (see below). 
Rejecting the simplest of them seems arbitrary and is (as is evident from the
duplicate requests) unhelpful to C programmers and surprising those used to the
C++ behavior.

$ cat a.c && gcc -S -Wall -Wpedantic a.c
#include 

_Static_assert (memcmp ("", "", 1) == 0, "");  // okay in C mode only
_Static_assert (memchr ("", 0, 1) != 0, "");   // okay in C mode only
_Static_assert (strlen ("") == 0, ""); // okay in C and C++
_Static_assert (strcmp ("", "") == 0, ""); // okay in C and C++
_Static_assert ("" == "", ""); // okay in C and C++

_Static_assert (*"" == 0, ""); // error in C only

a.c:3:36: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
3 | _Static_assert (memcmp ("", "", 1) == 0, "");  // okay in C mode only
  | ~~~^~~~
a.c:4:35: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
4 | _Static_assert (memchr ("", 0, 1) != 0, "");   // okay in C mode only
  | ~~^~~~
a.c:5:29: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
5 | _Static_assert (strlen ("") == 0, ""); // okay in C and C++
  | ^~~~
a.c:6:33: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
6 | _Static_assert (strcmp ("", "") == 0, ""); // okay in C and C++
  | ^~~~
a.c:7:20: warning: comparison with string literal results in unspecified
behavior [-Waddress]
7 | _Static_assert ("" == "", ""); // okay in C and C++
  |^~
a.c:7:20: warning: expression in static assertion is not an integer constant
expression [-Wpedantic]
7 | _Static_assert ("" == "", ""); // okay in C and C++
  | ~~~^
a.c:9:21: error: expression in static assertion is not constant
9 | _Static_assert (*"" == 0, ""); // error in C only
  | ^~~~

[Bug c/106988] New: subscripting a string literal is not an integer constant expression but __builtin_strlen is

2022-09-20 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106988

Bug ID: 106988
   Summary: subscripting a string literal is not an integer
constant expression but __builtin_strlen is
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C mode, GCC rejects a subscript expression whose operand is a string literal
in contexts where an integer constant expression is required but accepts an
equivalent expression involving __builtin_strlen.  Although conforming, it's
inconsistent and unnecessarily restrictive.  Accepting both (either with
-Wpedantic) would also be conforming and more useful to programmers who need it
but don't think of using the built-in workaround.

$ cat a.c && gcc -S -Wall -Wpedantic a.c
#define EMPTY1(S) (__builtin_strlen(S) == 0)
_Static_assert(!EMPTY1("1"), "");// ok

#define EMPTY2(S) (S[0] == 0)
_Static_assert(!EMPTY2("1"), "");// error
a.c:5:16: error: expression in static assertion is not constant
5 | _Static_assert(!EMPTY2("1"), "");// error
  |^

[Bug tree-optimization/106931] [12/13 Regression] -Wstringop-overflow false positive -O3 -fno-tree-vectorize with loop unrolling since r12-3300-gece28da924ddda8b

2022-09-13 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106931

Martin Sebor  changed:

   What|Removed |Added

Summary|[12/13 Regression]  |[12/13 Regression]
   |-Wstringop-overflow false   |-Wstringop-overflow false
   |positive  -O3   |positive  -O3
   |-fno-tree-vectorize since   |-fno-tree-vectorize with
   |r12-3300-gece28da924ddda8b  |loop unrolling since
   ||r12-3300-gece28da924ddda8b

--- Comment #2 from Martin Sebor  ---
The false positive is issued for the store to A[i_90] in BB 10 by the strlen
pass, where i_90's range is [8, 8].

   [local count: 712060]:
  _35 = (sizetype) i_90;
  _36 = B.1_83 + _35;
  _37 = *_36;
  A[i_90] = _37;<< -Wstringop-overflow
  _20 = _93 + 9;
  i_39 = (int) _20;
  goto ; [100.00%]

Changing i's type to unsigned avoids the warning.  The IL looks very close but
i_90's range in BB 10 is VR_UNDEFINED instead.

The following is debug_ranger() output for BBs 9 and 10 in the original test
case.

=== BB 9 
Imports: _93  
Exports: _8  i_90  _93  
 _8 : _93(I)  
 _86 : i_82(I)  
 _87 : i_82(I)  B.1_83(I)  _86  
 i_90 : _8  _93(I)  
i_82[irange] int [7, 7] NONZERO 0x7
_93 [irange] unsigned int [0, 0] NONZERO 0x0
Relational : (_8 > _93)
 [local count: 801058]:
_86 = (sizetype) i_82;
_87 = B.1_83 + _86;
_88 = *_87;
A[i_82] = _88;
_8 = _93 + 8;
i_90 = (int) _8;
if (i_90 != 8)
  goto ; [88.89%]
else
  goto ; [11.11%]

_8 : [irange] unsigned int [8, 8] NONZERO 0x8
_86 : [irange] sizetype [7, 7] NONZERO 0x7
_87 : [irange] char * [1, +INF]
i_90 : [irange] int [8, 8] NONZERO 0x8
9->10  (T) _8 : [irange] UNDEFINED
9->10  (T) i_90 :   [irange] UNDEFINED
9->10  (T) _93 :[irange] UNDEFINED
9->12  (F) _8 : [irange] unsigned int [8, 8] NONZERO 0x8
9->12  (F) i_90 :   [irange] int [8, 8] NONZERO 0x8
9->12  (F) _93 :[irange] unsigned int [0, 0] NONZERO 0x0

=== BB 10 
_93 [irange] UNDEFINED
 [local count: 712060]:
_35 = (sizetype) i_90;
_36 = B.1_83 + _35;
_37 = *_36;
A[i_90] = _37;
_20 = _93 + 9;
i_39 = (int) _20;
goto ; [100.00%]

whereas for the unsigned case:

=== BB 10 
_85 [irange] UNDEFINED
i_90[irange] UNDEFINED

[Bug tree-optimization/106868] [12/13 Regression] Bogus -Wdangling-pointer warning with -O1

2022-09-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868

--- Comment #3 from Martin Sebor  ---
(In reply to Martin Sebor from comment #2)
...
Actually, scratch that, sorry.  Richard is right that the false positive is due
to a bug in the warning code.  The following patch resolves it:

diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index 04aa849a4b1..79093b46906 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -4467,6 +4467,7 @@ pass_waccess::gimple_call_return_arg_ref (gcall *call)
 {
   access_ref aref;
   if (m_ptr_qry.get_ref (arg, call, &aref, 0)
+ && aref.deref < 0
  && DECL_P (aref.ref))
return aref.ref;
 }

[Bug tree-optimization/106868] [12/13 Regression] Bogus -Wdangling-pointer warning with -O1

2022-09-12 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106868

--- Comment #2 from Martin Sebor  ---
(In reply to Richard Biener from comment #1)
> Confirmed.
> 
>  [local count: 1073741824]:
> alloc (&q);
> q.0_1 = q;
> *p_4(D) = q.0_1;
> q ={v} {CLOBBER(eol)};
> a_8 = __builtin_memcpy (q.0_1, "", 1);
> *a_8 = 0;
> return;
...
> we somehow confuse q.0_1 = q; as assigning the address of the object 'q'.

The reason for the false positive is plain to see in the IL: the memcpy call is
passed a copy of the clobbered q.  It then returns another copy of the same q
which is then used to dereference whatever the pointer points to.  The warning
is due to the (known) mismatch between how the optimizers and the warning
interpret clobbers: (IIUC) the optimizers treat it as the value of the assigned
variable alone becoming indeterminate, while the warning as all copies of it
becoming so.

[Bug middle-end/106776] Unexpected use-after-free warning

2022-08-30 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106776

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
Reproduced with the following reduced test case:

$ cat pr106776.C && g++ -O2 -S -Wall pr106776.C
#include 

struct matrix_t
{
  int* count;

  matrix_t() :
count(new int(1)) {}

  matrix_t(const matrix_t& p) :
count(p.count) { ++*count; }

  ~matrix_t() { if (--*count == 0) { delete count; } }
};

typedef std::map cache_t;

cache_t CACHE;

matrix_t* cache(cache_t::iterator lb)
{
  matrix_t wftable;

  return &CACHE.insert(lb, cache_t::value_type(1, wftable))->second;
}
In destructor ‘matrix_t::~matrix_t()’,
inlined from ‘matrix_t* cache(std::map::iterator)’ at
pr106776.C:25:1:
pr106776.C:13:23: warning: pointer used after ‘void operator delete(void*,
std::size_t)’ [-Wuse-after-free]
   13 |   ~matrix_t() { if (--*count == 0) { delete count; } }
  |   ^~
In destructor ‘matrix_t::~matrix_t()’,
inlined from ‘std::pair::~pair()’ at
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_pair.h:187:12,
inlined from ‘matrix_t* cache(std::map::iterator)’ at
pr106776.C:24:37:
pr106776.C:13:45: note: call to ‘void operator delete(void*, std::size_t)’ here
   13 |   ~matrix_t() { if (--*count == 0) { delete count; } }
  | ^

The IL in shows the reason for the warning in bb 8 in struct matrix_t * cache
(struct iterator lb), seen in the output of -fdump-tree-waccess3:

  ...
   [local count: 335388518]:
  operator delete (_3, 4);  <<< _3 deleted
  pretmp_50 = MEM[(int *)_3];   <<< _3 dereferenced

[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop

2022-08-26 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106757

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-26
 Blocks||88443
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
Summary|[12/13 Regression]  |[12/13 Regression]
   |Incorrect "writing 1 byte   |Incorrect "writing 1 byte
   |into a region of size 0"|into a region of size 0" on
   |warning |a vectorized loop

--- Comment #1 from Martin Sebor  ---
GCC unrolls the loop, and GCC 12 also vectorizes it.  The combination of the
two isolates stores from the loop that are out of bounds but that GCC cannot
prove cannot happen: it has no insight into what value pqr_mbc_len() might
return and if it's 5 or more the code would indeed write past the end.  The
warning just points it out.  To "fix" this the unroller could use the bounds of
the destination array to avoid emitting code for iterations of the loop that
end up accessing objects outside their bounds (there already is logic that does
that, controlled by the -faggressive-loop-optimizations option).  Until then,
if the function is guaranteed to return a value between 0 and 4 then adding the
following assertion both avoids the warning and improves the emitted code.

if (len < 0 || MBC_MAX < len)
  __builtin_unreachable ();

The invalid stores can be seen in the IL output by the
-fdump-tree-strlen=/dev/stdout developer option:

   [local count: 76354976]:
  bnd.6_47 = _26 >> 2;
  vect__3.11_53 = MEM  [(char *)mbs_22];
  MEM  [(char *)&tmpchar] = vect__3.11_53;
  vectp_mbs.9_52 = mbs_22 + 4;
  niters_vector_mult_vf.7_48 = bnd.6_47 << 2;
  tmp.8_49 = (int) niters_vector_mult_vf.7_48;
  if (_26 == niters_vector_mult_vf.7_48)
goto ; [25.00%]
  else
goto ; [75.00%]

   [local count: 57266232]:
  _75 = (sizetype) tmp.8_49;
  _76 = vectp_mbs.9_52;
  _77 = MEM[(char *)vectp_mbs.9_52];
  tmpchar[tmp.8_49] = _77;   <<< -Wstringop-overflow
  k_79 = tmp.8_49 + 1;
  if (len_12 > 5)
goto ; [80.00%]
  else
goto ; [20.00%]

   [local count: 45812986]:
  _82 = 5;
  _83 = mbs_22 + 5;
  _84 = *_83;
  tmpchar[5] = _84;  <<< -Wstringop-overflow
  k_86 = tmp.8_49 + 2;
  if (len_12 > k_86)
goto ; [80.00%]
  else
goto ; [20.00%]


Referenced Bugs:

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

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

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 105348, which changed state.

Bug 105348 Summary: Overly aggressive -Warray-bounds after conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

[Bug middle-end/105348] Overly aggressive -Warray-bounds after conditional

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Resolved as invalid per comment #3.

[Bug tree-optimization/106247] GCC12 warning in Eigen: array subscript is partly outside array bounds

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed|2022-07-10 00:00:00 |2022-08-19
 Ever confirmed|0   |1
 CC||msebor at gcc dot gnu.org

--- Comment #5 from Martin Sebor  ---
This instance of -Warray-bounds (with the text "partly outside the bounds") is
often issued for aliasing violations where an object of one type is being
access by an lvalue of a larger struct.  The ultimate access may be to a member
of the larger struct whose offset is within the bounds of the smaller object,
but the access is (or could be) wrong nonetheless (due to the aliasing rules)
and hence the warning.

Here's an example:

$ cat a.c && gcc -O2 -S -Wall a.c
struct A { int i; };
struct B { struct A a; int j; };

void* f (void)
{
  struct A *p = __builtin_malloc (sizeof *p);
  ((struct B*)p)->a.i = 0;
  return p;
}
a.c: In function ‘f’:
a.c:7:17: warning: array subscript ‘struct B[0]’ is partly outside array bounds
of ‘unsigned char[4]’ [-Warray-bounds]
7 |   ((struct B*)p)->a.i = 0;
  | ^~
a.c:6:17: note: object of size 4 allocated by ‘__builtin_malloc’
6 |   struct A *p = __builtin_malloc (sizeof *p);
  | ^~~~

If your case is comparable this should be resolved as invalid; otherwise, if
it's substantially different please post a reproducible test case.

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

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 106446, which changed state.

Bug 106446 Summary: -Warray-bounds false positive on downcast under condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106446

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug tree-optimization/106446] -Warray-bounds false positive on downcast under condition

2022-08-19 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106446

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Martin Sebor  ---
The compiler doesn't know what D2::is_me() might return so it must emit code
for both branches in bar().  In the true branch, because struct D1 has no
member val, the warning triggers.  This is by design.

[Bug tree-optimization/106559] [10/11/12/13 Regression] Spurious warning -Wformat-truncation (regression from 9)

2022-08-16 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106559

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Blocks||85741

--- Comment #2 from Martin Sebor  ---
The warning triggers because it considers the size of the whole `string' array
passed as an argument to the %s directive.  It does that because the analysis
is unable to determine which array element the argument points to and it's not
"smart" enough to see that all the elements are strings of the same length. 
The output of the -fdump-tree-strlen option below helps see what's gooing on
(the numbers next  to each Result: show the minimum, maximum, likely, and
unlikely amount of output produced by the directive, with the corresponding
running totals in parentheses).

The problem can be reduced to a missed optimization opportunity in the test
following test case: the condition in each iteration of the loop is false so
the loop can be optimized away, but because of the incomplete analysis above it
is not.

void f (void)
{
  static const char string[16][3]={
  "01","02","03","04","05","06","07","08",
  "09","10","11","12","13","14","15","16"};

  for(unsigned int i=0; i<16; ++i)
  if (__builtin_strlen (string[i]) != 2)
  __builtin_abort ();
}

Short of improving the strlen optimization the warning could also be suppressed
by considering the cast in the assignment `_2 = (const char[3] *) ivtmp.11_15;'
and using the size of the array as the upper bound on the length of the string.
 (This wouldn't be safe for the optimization.)

Until this is fixed in GCC, the warning can be suppressed and the emitted code
improved by asserting in each iteration that the length of the string is (at
most) two, like so:

if (__builtin_strlen (string[i]) != 2)
  __builtin_unreachable ();

pr106559.c:11: __builtin_snprintf: objsize = 64, fmtstr = "%u (%s):   %8x"
  Directive 1 at offset 0: "%u"
Result: 1, 2, 2, 2 (1, 2, 2, 2)
  Directive 2 at offset 2: " (", length = 2
Result: 2, 2, 2, 2 (3, 4, 4, 4)
  Directive 3 at offset 4: "%s"
Result: 0, 47, 47, 9223372036854775807 (3, 51, 51, -9223372036854775805)
  Directive 4 at offset 6: "):   ", length = 5
Result: 5, 5, 5, 5 (8, 56, 56, -9223372036854775800)
  Directive 5 at offset 11: "%8x"
Result: 8, 8, 8, 8 (16, 64, 64, -9223372036854775792)
  Directive 6 at offset 14: "", length = 1
pr106559.c: In function ‘f’:
pr106559.c:11:61: warning: ‘__builtin_snprintf’ output may be truncated before
the last format character [-Wformat-truncation=]
   11 | __builtin_snprintf(buffer,sizeof(buffer),"%u (%s):   %8x",
  | ^
pr106559.c:11:5: note: ‘__builtin_snprintf’ output between 17 and 65 bytes into
a destination of size 64
   11 | __builtin_snprintf(buffer,sizeof(buffer),"%u (%s):   %8x",
  | ^~
   12 |   i,string[i],number[i]);
  |   ~~

void f ()
{
  unsigned long ivtmp.11;
  unsigned long ivtmp.5;
  unsigned int i;
  static const char string[16][3] = {"01", "02", "03", "04", "05", "06", "07",
"08", "09", "10", "11", "12", "13", "14", "15", "16"};
  unsigned int _1;
  const char[3] * _2;
  unsigned int _18;

   [local count: 63136016]:
  ivtmp.11_17 = (unsigned long) &string;

   [local count: 1010605809]:
  # ivtmp.5_13 = PHI 
  # ivtmp.11_15 = PHI 
  _18 = (unsigned int) ivtmp.5_13;
  _1 = MEM[(unsigned int *)&number + ivtmp.5_13 * 4];
  _2 = (const char[3] *) ivtmp.11_15;<<< cast
not considered
  __builtin_snprintf (&buffer, 64, "%u (%s):   %8x", _18, _2, _1);   <<<
warning here for _2


Referenced Bugs:

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

[Bug c/100420] unspecified VLA bound formatted as [0] instead of [*] in -Wvla-parameter

2022-08-16 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100420

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-08-16
  Known to fail||11.1.0, 12.1.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 11 and 12.

[Bug c/101605] bogus -Wvla-parameter in same bound expression with differently named parameters

2022-08-16 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101605

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2021-07-23 00:00:00 |2022-08-16
  Known to fail||11.1.0, 12.1.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Sebor  ---
Confirmed with GCC 11 and 12.

[Bug middle-end/98109] Seemingly wrong warnings from -Wnonnull when combined with -O2 -fsanitize=undefined

2022-08-01 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98109

--- Comment #5 from Martin Sebor  ---
(In reply to Bernd Buschinski from comment #4)
> Can someone tell me if this should be a new bug or is just a duplicate?

It's the same bug.  The sanitizer transforms the source code into the following
IR (note the 0B argument to my_memmem):

   [local count: 390331996]:
  if (str_path$buffer_7 == 0B)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin___ubsan_handle_nonnull_arg (&*.Lubsan_data2);
  _12 = my_memmem (0B, str_path$length_11, ".abcd", 5);   <<< warning here
  if (_12 != 0B)
goto ; [54.59%]
  else
goto ; [45.41%]

[Bug tree-optimization/106297] [12/13 Regression] stringop-overflow misbehaviour on atomic since r12-4725-g88b504b7a8c5affb

2022-07-28 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297

Martin Sebor  changed:

   What|Removed |Added

  Known to fail||12.1.0, 13.0
 Blocks||88443
   Keywords||missed-optimization

--- Comment #6 from Martin Sebor  ---
There have been other reports of false positives due to the same issue (e.g.,
some or all of pr65461, pr92539, pr92955, pr95140, and pr96447).  Since the
unrolling pass uses the invalid access to decide to unroll the loop maybe it
could insert the __builtin_unreachable() call before it (or instead of it)
rather than after it.  That way the bad access would get eliminated and the
warning avoided.  Or, it could, in addition to inserting the
__builtin_unreachable() call after it, also suppress the access warning for the
bad statement.  Alternatively, these problems could be worked around in the
warning code by suppressing it in basic blocks that terminate by a call to
unreachable.  But this would cause false negatives where the unreachable call
is added after real problems in the user's source).

Until this is solved in GCC it can be dealt with in user code by asserting the
loop doesn't iterate more times than there are elements in the array.  In the
test case in comment #5 that might look like so:

  if (n >= sizeof s / sizeof *s)
__builtin_unreachable ();


Referenced Bugs:

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

[Bug middle-end/105746] vector::resize causes Warray-bounds when optimizer uses __builtin_memcpy or __builtin_memmove since r12-2793-g81d6cdd335ffc60c

2022-07-15 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105746

Martin Sebor  changed:

   What|Removed |Added

  Component|c++ |middle-end

--- Comment #2 from Martin Sebor  ---
The memmove call in the IL the warning is issued for writes past the end of the
allocated block.  My guess is that the call to operator new prevents it from
figuring out that the _M_finish initially zeroed out by the vectorized store to
vectp.132_96 is still clear in bb 5.  This can be confirmed by replacing the
call to operator new with one to __builtin_malloc() which both eliminates the
warning and also results in much more efficient code(*).  There are duplicates
of this problem in Bugzilla.  The root cause is probably the fix for pr101480.

   [local count: 1073741824]:
  vectp.132_96 = &MEM[(struct _Vector_impl_data *)v_2(D)]._M_start;
  MEM  [(union U * *)vectp.132_96] = { 0, 0 };  
<<< zero out _M_finish (and _M_start)
  MEM[(struct _Vector_impl_data *)v_2(D)]._M_end_of_storage = 0B;
  _70 = operator new (100);

   [local count: 1073741824]:
  __builtin_memset (_70, 255, 100);
  _78 = v_2(D)->D.25350._M_impl.D.24657._M_start;<<< zero
  if (_78 != 0B)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 439275554]:   <<< unreachable 
  # __cur_127 = PHI <__cur_83(4), _70(3)>
  # __first_120 = PHI <__first_82(4), _78(3)>
  *__cur_127 ={v} {CLOBBER};
  _81 = MEM[(const union U &)__first_120];
  MEM[(union U *)__cur_127] = _81;
  __first_82 = __first_120 + 1;
  __cur_83 = __cur_127 + 1;
  goto ; [100.00%]

   [local count: 54292484]:
  __new_finish_85 = _70 + 100;
  _86 = v_2(D)->D.25350._M_impl.D.24657._M_finish;   <<< zero
  if (_86 != 0B)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 48320311]:<<< unreachable
  _93 = (sizetype) _86;  <<< zero
  __builtin_memmove (__new_finish_85, 0B, _93);  <<< warning
  ...


The IL for the function when operator new is replaced with __builtin_malloc:

struct vector bug ()
{
  union U * __new_finish;
  union U * __cur;
  long unsigned int __n;
  union U * _70;

   [local count: 1073741824]:
  _70 = __builtin_malloc (100);
  __builtin_memset (_70, 255, 100);
  __new_finish_84 = _70 + 100;
  v_2(D)->D.25350._M_impl.D.24657._M_start = _70;
  v_2(D)->D.25350._M_impl.D.24657._M_finish = __new_finish_84;
  v_2(D)->D.25350._M_impl.D.24657._M_end_of_storage = __new_finish_84;
  return v_2(D);

}

[Bug c/106264] [10/11/12/13 Regression] spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result

2022-07-11 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264

--- Comment #2 from Martin Sebor  ---
The most likely culprit is r261705.

[Bug c/106264] New: spurious -Wunused-value on a folded frexp, modf, and remquo calls with unused result

2022-07-11 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106264

Bug ID: 106264
   Summary: spurious -Wunused-value on a folded frexp, modf, and
remquo calls with unused result
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

In C mode only the following test case triggers the invalid (or at least poorly
worded and so confusing) instances of -Wunused-value.  Each instance goes away
when the call is not folded or when its result is used.  The C++ front end
doesn't warn.

$ cat a.c && gcc -O -Wall -S -Wall a.c
double frexp (double, int*);
double modf (double, double*);
double remquo (double, double, int*);

int f (void)
{
  int y;
  frexp (1.0, &y);
  return y;
}

double g (void)
{
  double y;
  modf (1.0, &y);
  return y;
}

int h (void)
{
  int y;
  remquo (1.0, 1.0, &y);
  return y;
}

a.c: In function ‘f’:
a.c:8:3: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
8 |   frexp (1.0, &y);
  |   ^~~
a.c: In function ‘g’:
a.c:15:3: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
   15 |   modf (1.0, &y);
  |   ^~
a.c: In function ‘h’:
a.c:22:3: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
   22 |   remquo (1.0, 1.0, &y);
  |   ^

[Bug tree-optimization/97185] inconsistent builtin elimination for impossible range

2022-06-14 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97185

--- Comment #2 from Martin Sebor  ---
There's a heuristic for ranges of allocation sizes to exclude zero
(size_range_flags) that comes into play here.  The actual range isn't
"impossible" in the sense it's necessarily invalid.  It just means the string
function call is either a no-op or out of bounds, and so can be eliminated as
an optimization.  With the optimization consistently implemented the warning
will also go away (eliminating the calls will prevent sanitizers from detecting
the out of bounds ones, so that might be a consideration).

In general, a low > high range denoted an anti-range before Ranger was
introduced (i.e., ~[high, low]).  With Ranger it's the corresponding union of
two ranges.  Some of the cruft for dealing with anti-ranges is still around,
such as in get_size_range() in pointer-query.cc.  The code should be migrated
to the irange class and the representation probably also updated to print
something more sensible (e.g., the union [MIN, high) U (low, MAX]; we talked
about introducing a pretty-printer % directive for ranges to make the format
consistent across all diagnostics).

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

2022-06-13 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

--- Comment #20 from Martin Sebor  ---
Well, I just "asked" for such an option the same way you asked for
-fstrict-flex-arrays in comment #3, because I believe it would be useful to
make the BOS improvements you're looking for available even to code that can't
do a whole-hog replacement of all trailing arrays with flexible array members. 
The spelling of the option names doesn't seem important to me (they could be
separate options, or the same one with an argument).

[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails

2022-06-13 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836

--- Comment #18 from Martin Sebor  ---
The zero size case exists (and is documented) solely as a substitute for
flexible array members.  Treating is as an ordinary array would disable that
extension.  It might be appropriate to provide a separate option to control it
but conflating it with the other cases (one or more elements) doesn't seem like
the robust design.

As I mentioned in the review of the Clang change,
https://reviews.llvm.org/D126864, so that code bases that use some larger
number of elements than zero, such as one, and that can't easily change, can
still benefit from the BOS enhancement for the remaining cases, it would be
helpful for the new option to accept the minimum number of elements at which a
trailing array ceases to be considered a poor-man's flexible array member.

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

2022-05-31 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 105762, which changed state.

Bug 105762 Summary: [12/13 Regression] -Warray-bounds false positives for 
integer-to-pointer casts since r12-2132-ga110855667782dac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug middle-end/105762] [12/13 Regression] -Warray-bounds false positives for integer-to-pointer casts since r12-2132-ga110855667782dac

2022-05-31 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105762

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |INVALID
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99578
 Status|NEW |RESOLVED

--- Comment #2 from Martin Sebor  ---
There is no object at address 1 (or at any "made up" address) so dereferencing
that address is undefined.  The warning is designed to detect accesses at
nonzero offsets from null (e.g., p->x or p[i]).  It was relaxed to accommodate
a subset of the use cases where the offset is above 4k (see pr99578).

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

2022-05-25 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84774
Bug 84774 depends on bug 93517, which changed state.

Bug 93517 Summary: bogus -Wrestrict on sprintf with unknown strings bounded by 
array size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93517

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

[Bug middle-end/93517] bogus -Wrestrict on sprintf with unknown strings bounded by array size

2022-05-25 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93517

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Martin Sebor  ---
I'm not able to reproduce the warning with any released version, or on trunk.

[Bug middle-end/105604] [10/11/12 Regression] ICE: in tree_to_shwi with vla in struct and sprintf

2022-05-24 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105604

Martin Sebor  changed:

   What|Removed |Added

Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE:
   |ICE: in tree_to_shwi with   |in tree_to_shwi with vla in
   |vla in struct and sprintf   |struct and sprintf
 Blocks||84774

--- Comment #5 from Martin Sebor  ---
Fixed on trunk.  The changes should be safe to backport after some time.


Referenced Bugs:

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

[Bug c/105689] Bogus `-Wstringop-overflow=` after accessing field, then containing struct (wrong "region size")

2022-05-23 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105689

--- Comment #2 from Martin Sebor  ---
It is because of CSE.  The warning sees this IL:

  _1 = &me_3(D)->sub.field1;
  access_1 (_1);
  access_2 (_1);

and so it warns for the second call because the size of me->sub.field1 passed
to it is smaller than struct subobject.  The attribute access on access_2() is
what tells it to use the size of struct subobject.

The CSE substitution causes false positives in other contexts besides calls to
functions with attribute access.  IIRC, one of the ideas for dealing with this
we discussed was to have CSE use the largest subobject instead whatever it
comes across first.

[Bug tree-optimization/105585] [12/13 Regression] Spurious stringop-overflow warning with since r12-4725-g88b504b7a8c5affb

2022-05-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105585

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|NEW |RESOLVED

--- Comment #4 from Martin Sebor  ---
The warning is caused by the if statement: if p is null, accessing the p->a
member is undefined.  It triggers because the GCC optimizer splits the code
into two branches: one with a nonnull p and another with a null p.  The second
one triggers the warning.

If p can be null then moving the increment to the body of the if statement
avoids the undefined behavior (and the warning).  If p cannot be null then
making the if statement unconditional also avoids the warning.

[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

2022-03-23 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970

--- Comment #10 from Martin Sebor  ---
The purpose of the internal_p flag documented in the attr_access class is more
general than to tell a VLA-like argument from an ordinary array/pointer form
("Set for an attribute added internally rather than by an explicit
declaration") so tying the two together would be fragile.  I expect using
internal_p directly as Siddhesh suggests will probably work now but I would
recommend using the vla_bounds() member function instead in case things change
in the future.

[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

2022-03-21 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970

--- Comment #7 from Martin Sebor  ---
The dollar sign in the internal attr_access string implies a VLA bound and the
attr_access::vla_bounds() function queries the VLA bounds.  That should make it
possible to distinguish the two cases.

Unlike the top-level VLA [N] notation which (unfortunately) implies no size
constraint on the actual argument, attribute access is meant to imply that the
array must have at least N elements (i.e., it's equivalent to [static N]).

As an aside, the tests cases in r12-6480 exercise only a small subset of
possible use cases: BDOS mode 0 results for calls to a function with attribute
access with either a dynamic size (known and unknown result) and a constant
size equal to array size.  There are many more use cases that aren't being
tested  that should be (e.g., larger or smaller arrays of constant size than
the size argument indicates with BDOS modes other than 0).

[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

2022-03-21 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970

--- Comment #5 from Martin Sebor  ---
Incidentally, __builtin_dynamic_object_size returns the size of a VLA parameter
in both mininum and maximum modes.  In f0 below, the size of the A array is at
least N bytes but it could be more, so based on my reading of the manual, it
seems like f0 is actually supposed return -1 (f1 looks fine).  If my reading is
correct that would seem unfortunate because it would basically makes BDOS
ineffective for _FORTIFY_SOURCE of VLA parameters.

long f0 (int n, char a[static n])
{
  return __builtin_dynamic_object_size (a, 0);   // folded to n, should be -1?
(Clang folds to -1)
}

long f1 (int n, char a[static n])
{
  return __builtin_dynamic_object_size (a, 1);   // folded to n (Clang folds to
-1)
}

Even more unfortunate seems that that without the [static] it's not undefined
to pass an array with fewer elements than the VLA bound indicates to a function
like f0 of f1.  GCC BDOS doesn't seem to consider the [static] notation and
folds the result the same way either way.  So while well-written code will
benefit from the stricter runtime checking made possible by the tighter bound,
it will cause aborts for poorly written code that's strictly valid.  If I'm
right about this, adding a permissive mode to BDOS to accommodate the poorly
written but valid code might be a way out.

There are cases when __builtin_dynamic_object_size could put the VLA bounds to
use, although I suspect they don't mater for _FORTIFY_SOURCE; if they should
matter, the brute force pr97172 fix might need to be revisited and the bounds
somehow preserved  Here are some such use cases:

$ cat c.c && gcc -O -S c.c
long f0 (int n, char a[static n])
{
  return __builtin_dynamic_object_size (a, 1);   // folded to n
}

long f1 (int n, char (*a)[n])
{
  return __builtin_dynamic_object_size (*a, 1);   // folded to -1 (fold to n?)
}

long f2 (int n, char a[1][n])
{
  return __builtin_dynamic_object_size (a[0], 1);   // folded to -1 (fold to
n?)
}

long f3 (int n, char a[static 1][n])
{
  return __builtin_dynamic_object_size (a, 1);   // ICE (fold to n?)
}

[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b

2022-03-21 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970

--- Comment #4 from Martin Sebor  ---
The VLA bounds were removed from parameter declarations in the fix for pr97172;
there weren't relied on by middle-end warnings then and still aren't today.

[Bug middle-end/104854] -Wstringop-overread should not warn for strnlen, strndup and strncmp

2022-03-18 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Martin Sebor  ---
I forgot this strndup pitfall that POSIX cautions about in its APPLICATION
USAGE and that the warning helps avoid:

  Implementations are free to malloc() a buffer containing either (size + 1)
bytes or (strnlen(s, size) + 1) bytes.  Applications should not assume that
strndup() will allocate (size + 1) bytes when strlen(s) is smaller than size.

Most implementations, including Glibc, only allocate strnlen (s, size) (i.e.,
less than size if s is shorter).

Since the only motivating test case here is strndup and since it turned out
that the patch submitted for this report was based on a misunderstanding of the
warning (https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591926.html) and
didn't do anything for strndup I'm going to resolve this as invalid.

If you want to raise problems about the warning for strnlen or strncmp please
open separate bugs and attach test cases, preferably from real code.  None of
those provided by Steve Grubb appears to have anything to do with strnlen or
strncmp.

[Bug c++/69517] SEGV on a VLA with excess initializer elements

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #19 from Martin Sebor  ---
I'm no longer working on this.

[Bug middle-end/71319] unnecessary call to __strcat_chk emitted after buffer reset

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71319

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I'm no longer working on this.

[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741
Bug 85741 depends on bug 77721, which changed state.

Bug 77721 Summary: -Wformat-truncation not uses arg range for converted vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77721

   What|Removed |Added

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

[Bug middle-end/77721] -Wformat-truncation not uses arg range for converted vars

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77721

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Blocks||85741
 Resolution|--- |FIXED

--- Comment #8 from Martin Sebor  ---
This appears fixed in GCC 12 and 11 (and perhaps even earlier).


Referenced Bugs:

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

[Bug c/79554] Zero length format string passed to fprintf under if statement causes error message

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79554

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I'm no longer working on this.

[Bug middle-end/82601] missing uninitialized warning for INTENT(OUT) argument with -O0 / -Og

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82601

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC|msebor at gcc dot gnu.org  |

--- Comment #6 from Martin Sebor  ---
I'm no longer working on this.

[Bug tree-optimization/82608] missing -Warray-bounds on an out-of-bounds VLA index

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82608

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
I'm no longer working on this.

[Bug c++/83429] Incorrect line number reported by -Wformat-truncation

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83429

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
GCC 11 and 12 print the following for the test case in comment #0.  I believe
the problem has been resolved (the %G format is gone now from 12).

pr83429.c: In function ‘void test(S*)’:
pr83429.c:12:42: warning: ‘%s’ directive output may be truncated writing up to
9 bytes into a region of size between 5 and 14 [-Wformat-truncation=]
   12 | snprintf(s->out, sizeof(s->out), "%s.%s", s->str1, s->str2); //
line 12
  |  ^~
pr83429.c:12:13: note: ‘snprintf’ output between 2 and 20 bytes into a
destination of size 15
   12 | snprintf(s->out, sizeof(s->out), "%s.%s", s->str1, s->str2); //
line 12
  | ^~~

[Bug tree-optimization/84561] -Wstringop-truncation with -O2 depends on strncpy's size type

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84561

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
The warning is still present in GCC 12.  I'm no longer working on this.

[Bug tree-optimization/84577] snprintf with null buffer not eliminated when return value is in a known range

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84577

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Known to fail||10.2.0, 11.2.0, 12.0
   Assignee|msebor at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #5 from Martin Sebor  ---
No changed in GCC 12 but I'm no longer working on this.

[Bug ipa/84603] -finline-limit not accepted in attribute and #pragma optimize

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84603

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
I'm no longer working on this.

[Bug tree-optimization/85650] Additional warnings when -fsanitize=undefined is used with -Wstringop-truncation

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85650

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I'm no longer working on this.

[Bug tree-optimization/87034] [9/10/11/12 Regression] missing -Wformat-overflow on a sprintf %s with a wide string

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87034

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Sebor  ---
I'm no longer working on this.

[Bug middle-end/88059] Spurious stringop-overflow warning with strlen, malloc and strncpy

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88059

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
I'm no longer working on this.

[Bug tree-optimization/88771] Misleading -Werror=array-bounds error

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #26 from Martin Sebor  ---
I'm no longer working on this.

[Bug middle-end/88780] [9/10/11/12 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
I'm no longer working on this.

[Bug tree-optimization/89678] Bogus -Wstringop-truncation on strncat with bound that depends on strlen of source

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89678

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I'm no longer working on this.

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

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
Bug 56456 depends on bug 90752, which changed state.

Bug 90752 Summary: missing -Warray-bounds accessing the result of string 
functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90752

   What|Removed |Added

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

[Bug tree-optimization/90752] missing -Warray-bounds accessing the result of string functions

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90752

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
GCC 12 warns as expected:

$ gcc -O2 -S -Wall pr90752.c 
pr90752.c: In function ‘f’:
pr90752.c:7:11: warning: array subscript -1 is outside array bounds of
‘char[4]’ [-Warray-bounds]
7 |   return p[-1];   // missing -Warray-bounds
  |  ~^~~~
pr90752.c:2:13: note: at offset -1 into object ‘a’ of size 4
2 | extern char a[4];
  | ^
pr90752.c: In function ‘g’:
pr90752.c:13:11: warning: array subscript [-5, -2] is outside array bounds of
‘char[4]’ [-Warray-bounds]
   13 |   return p[-5];   // missing -Warray-bounds
  |  ~^~~~
pr90752.c:2:13: note: at offset [-5, -2] into object ‘a’ of size 4
2 | extern char a[4];
  | ^
pr90752.c: In function ‘h’:
pr90752.c:19:11: warning: array subscript 4 is outside array bounds of
‘char[4]’ [-Warray-bounds]
   19 |   return p[4];   // missing -Warray-bounds
  |  ~^~~
pr90752.c:2:13: note: at offset 4 into object ‘a’ of size 4
2 | extern char a[4];
  | ^

[Bug middle-end/90904] vec assignment and copying undefined

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90904

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
I'm no longer working on this.

[Bug middle-end/90959] hash_map can be copied but leads to a double-free after assignment

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90959

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I'm no longer working on this.

[Bug driver/90983] [9 Regression] manual documents `-Wno-stack-usage` flag, but it is unrecognized

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90983

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
Fixed, won't backport.

[Bug c++/91076] wrong class-key in mentioned in a diagnostic note

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91076

Martin Sebor  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/91147] strlen of conditional plus index in known range not folded

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91147

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
I'm no longer working on this.

[Bug middle-end/91490] [9 Regression] bogus argument missing terminating nul warning on strlen of a flexible array member

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91490

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Sebor  ---
I'm no longer planning to backport the fix.

[Bug middle-end/91584] [9 Regression] Bogus warning from -Warray-bounds during string assignment

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91584

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
I'm no longer planning to backport the fix.

[Bug middle-end/91848] missing warning on strcpy past the end of a member of an array with variable index

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91848

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
I'm no longer working on this.

[Bug ipa/92799] [9 Regression] ICE on a weakref function definition followed by a declaration

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92799

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Sebor  ---
I'm not planning to backport the fix.

[Bug c/94040] [9 Regression] ICE on a call to an invalid redeclaration of strftime

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94040

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
I'm not planning to backport the fix.

[Bug c++/94346] [9 Regression] ICE due to handle_copy_attribute since r9-3982

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94346

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
I'm no longer planning to backport the fix.

[Bug tree-optimization/94655] [10 Regression] -Wstringop-overflow on implicit string assignment with vectorized char store

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #18 from Martin Sebor  ---
I'm no longer planning to bakcport the fix.

[Bug c++/94923] False positive -Wclass-memaccess with trivially copyable std::optional

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94923

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed per comment #6.

[Bug middle-end/95072] [10/11/12 Regression] -Warray-bounds false positive with flexible array bounds (regression from GCC 9)

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95072

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
The warning is still present in GCC 12.  I'm no longer working on it.

[Bug middle-end/95189] [9 Regression] memcmp being wrongly stripped like strcmp

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95189

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #32 from Martin Sebor  ---
I'm not planning to backport the patch.

[Bug c/96171] [10 Regression] ICE on invalid VLA argument declaration and attribute access

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96171

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I'm no longer planning to backport the fix.

[Bug tree-optimization/96963] [10 Regression] -Wstringop-overflow false positive on -O3 or -O2 -ftree-vectorize when assigning consecutive char struct members

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96963

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #14 from Martin Sebor  ---
I'm no longer planning to backport this.

[Bug c/101289] [11 Regression] bogus -Wvla-paramater warning when using const for vla param

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101289
Bug 101289 depends on bug 97548, which changed state.

Bug 97548 Summary: [11 Regression] bogus -Wvla-parameter on a bound expression 
involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548

   What|Removed |Added

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

[Bug c/101604] [meta-bug] bogus/missing -Wvla-parameter

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101604
Bug 101604 depends on bug 97548, which changed state.

Bug 97548 Summary: [11 Regression] bogus -Wvla-parameter on a bound expression 
involving a parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548

   What|Removed |Added

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

[Bug c/97548] [11 Regression] bogus -Wvla-parameter on a bound expression involving a parameter

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97548

Martin Sebor  changed:

   What|Removed |Added

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

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

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

2022-03-17 Thread 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

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

--- Comment #6 from Martin Sebor  ---
I'm no longer planning to backport the fix.

[Bug tree-optimization/99121] [9/10/11 Regression] ICE tree check: expected integer_cst, have var_decl in get_len, at tree.h:6037

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99121

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Fixed in GCC 12.  It could be fixed on release branches but I'm no longer
working on it.

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

2022-03-17 Thread 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

   Assignee|msebor at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
 Status|ASSIGNED|RESOLVED
 CC|msebor at gcc dot gnu.org  |
 Resolution|--- |FIXED

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

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

2022-03-17 Thread 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|msebor at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org
Summary|[10/11/12 Regression] bogus |[10/11 Regression] bogus
   |-Warray-bounds accessing an |-Warray-bounds accessing an
   |array element of empty  |array element of empty
   |structs |structs
  Known to work||12.0
 Status|ASSIGNED|NEW

--- Comment #4 from Martin Sebor  ---
This has been fixed in GCC 12.  I'm not planning to backport it.

[Bug middle-end/101665] -fno-delete-null-pointer checks ineffective for attribute nonnull parameters

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101665

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I'm no longer working on this.

[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #22 from Martin Sebor  ---
I'm no longer working on this.

[Bug middle-end/104076] bogus -Wdangling-pointer on a conditional

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
I'm no longer working on this.

[Bug tree-optimization/84050] [9/10/11/12 Regression] missing -Warray-bounds accessing a struct array member

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84050

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Sebor  ---
I'm no longer working on this.

[Bug c++/84318] [9/10/11/12 Regression] attribute deprecated on function templates different than class templates

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84318

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
I'm no longer working on this.

[Bug c++/83430] missing warning for specifying larger snprintf bound than destination size

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83430

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
I'm no longer working on this.


Referenced Bugs:

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

[Bug tree-optimization/80420] missing -Wformat-overfow on snprintf with excessive bound

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80420

Martin Sebor  changed:

   What|Removed |Added

 Blocks||85741
 Status|ASSIGNED|NEW

--- Comment #1 from Martin Sebor  ---
I'm no longer working on this.


Referenced Bugs:

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

[Bug c++/70588] SIGBUS on a VLA larger than SIZE_MAX / 2

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70588

Martin Sebor  changed:

   What|Removed |Added

   Assignee|msebor at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #14 from Martin Sebor  ---
I'm no longer working on this.

[Bug c++/70076] no exception for excess initializer elements in a multidimensional VLA

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70076

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
I'm no longer working on this.

[Bug c/67872] missing -Warray-bounds warning, bogus -Wmaybe-uninitialized

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67872

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
I'm no longer working on this.

[Bug preprocessor/41540] -dM -E doesn't #define __FILE__

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41540

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
No longer working on this.

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

2022-03-17 Thread 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

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

--- Comment #21 from Martin Sebor  ---
Deferring to Andrew per comment #19.

[Bug tree-optimization/104969] Likely a false positive of -D_FORTIFY_SOURCE=3

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104969

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
That's not the intended reading of the POSIX text.  But (outside of extensions
for behavior C leaves undefined) POSIX defers to C, so the authoritative text
is there.  C doesn't impose any requirement on the size argument.

That said, specifying a snprintf size that's bigger than the space in the
provided buffer is certainly asking for trouble, even more so than doing the
same with strncmp.  GCC should be enhanced to warn about that when possible
(pr83430 tracks the request), although I suspect that wouldn't help in this
case.

For the constant subset of instances Clang issues warning: 'snprintf' size
argument is too large; destination buffer has size 4, but size argument is 7
[-Wfortify-source].

[Bug middle-end/104965] [11/12 Regression] Yet another -Warray-bounds false positive

2022-03-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104965

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
It looks like an escape analysis limitation.  With this simpler test case using
different types to rule out aliasing assumptions:

#include 

int main()
{
  std::basic_string s;
  auto p = new int[s.size ()]{ };
  char c = 0;
  if (s.size())
c = *p;
  delete[] p;
  return c;
}

pr104965.C:9:9: warning: array subscript 0 is outside array bounds of ‘void
[0]’ [-Warray-bounds]
9 | c = *p;
  | ^~
pr104965.C:6:34: note: object of size 0 allocated by ‘operator new []’
6 |   auto p = new short[s.size ()]{ };
  |  ^

One of the stores to the local s escapes its address which is then assumed to
have been clobbered by operator new:

   [local count: 1073741824]:
  s ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&s] ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)&s]._M_p = &s.D.33279._M_local_buf;
  s._M_string_length = 0;
  MEM[(char_type &)&s + 16] = 0;
  _5 = operator new [] (0);

   [local count: 1073741824]:
  _10 = s._M_string_length;
  if (_10 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _1 = MEM[(int *)_5];
  c_6 = (char) _1;

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

2022-03-16 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578

--- Comment #31 from Martin Sebor  ---
I suppose we could move this warning under level 2 until this is handled
better.  -Warray-bounds already has two levels with level 2 being more noisy,
and it might be useful to add a level to -Wstringop-overread as well.

As I mentioned in comment #25 and elsewhere, I envisioned that code would
annotate these hardwired addresses somehow, ideally using an attribute like
addr or the Keil compiler's at (see below), or until one is added, using a
workaround like your absolute_pointer().  I realize it means work, but I
believe with the attribute the gain in type safety would make it worthwhile. 
Is that something the kernel developers could be trained to start using?  (In
full disclosure, I don't expect to have the cycles to work on the attribute
anytime soon.)

https://www.keil.com/support/man/docs/armcc/armcc_chr1359124981140.htm

[Bug middle-end/104492] [12 Regression] Bogus dangling pointer warning at -O3

2022-03-16 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
So the CLOBBER semantics correspond more closely to those of a C++ destructor
than to a deallocation call.  It would be helpful to document these things.

  1   2   3   4   5   6   7   8   9   10   >