[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

2020-11-16 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Implemented for GCC 11.

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

2020-11-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:b1ecb86569f63f897f6a95049c4ccf400bddeaad

commit r11-5072-gb1ecb86569f63f897f6a95049c4ccf400bddeaad
Author: Martin Sebor 
Date:   Mon Nov 16 19:47:39 2020 -0700

PR middle-end/95673 - missing -Wstring-compare for an impossible strncmp
test

gcc/ChangeLog:

PR middle-end/95673
* tree-ssa-strlen.c (used_only_for_zero_equality): Rename...
(use_in_zero_equality): ...to this.  Add a default argument.
(handle_builtin_memcmp): Adjust to the name change above.
(handle_builtin_string_cmp): Same.
(maybe_warn_pointless_strcmp): Same.  Pass in an explicit argument.

gcc/testsuite/ChangeLog:

PR middle-end/95673
* gcc.dg/Wstring-compare-3.c: New test.

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

2020-10-01 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Keywords||patch

--- Comment #7 from Martin Sebor  ---
Patch to enhance the warning:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555225.html

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

2020-09-30 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673

Martin Sebor  changed:

   What|Removed |Added

 Blocks||83819

--- Comment #6 from Martin Sebor  ---
There warning doesn't trigger for the first strcmp call (i.e., strcmp(file,
"file123.txt")) because it's folded into a conditional expression involving
just the lengths of the strings before it reaches the stage when it would
otherwise be issued.

Here's a small test case showing how it happens:

  int f (int c)
  {
const char *s = c ? "12345" : "12";
return 0 == __builtin_strcmp (s, "123");
  }

and the output pf the PRE pass (-fdump-tree-pre-details) shows:

...
Found partial redundancy for expression
{call_expr<__builtin_strcmp>,iftmp.0_3,addr_expr<"123">}@.MEM_5(D) (0001)
Created phi prephitmp_7 = PHI <-1(3), 1(5)>
 in block 4 (0001)
Starting insert iteration 2
Replaced 0 with pretmp_11 in all uses of pretmp_9 = 0;
Replaced 0 with pretmp_10 in all uses of pretmp_8 = 0;
Replaced __builtin_strcmp (iftmp.0_3, "123") with prephitmp_7 in all uses of _1
= __builtin_strcmp (iftmp.0_3, "123");
...
Removing dead stmt _1 = __builtin_strcmp (iftmp.0_3, "123");
...

The PRE pass runs much earlier than the strlen pass that issues the warning so
I don't think there's going to be anything to emit the warning in this case
(involving all string literals).

The PRE optimization isn't smart enough to handle the case when at least one of
the arguments is an ordinary array and so then warning does trigger:

  extern char a[3];

  int f (int c)
  {
const char *s = c ? "12345" : a;
return 0 == __builtin_strcmp (s, "123");
  }

The call is then folded away by the strlen pass (by the same code that issues
the warning).

In general, the warning code doesn't necessarily know the contents of the
arrays it's based on, only their lengths and/or sizes, so it can't very well
print them.  (Printing strings is also tricky because of constraints on the
volume of output, or the question how to deal with non-printable characters.)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

2020-09-29 Thread sirl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673

Franz Sirl  changed:

   What|Removed |Added

 CC||sirl at gcc dot gnu.org

--- Comment #5 from Franz Sirl  ---
Wstring-compare seems to depend a lot on the optimizations. In the following
testcase warnings are also inconsistent and fragile (slight changes make the
warning disappear):

int c, d, e;
void f(void) {
  const char *file = (c & 7) ? "file1234.txt" : "x";
  const char *file2 = (c & 7) ? "y" : "file12.txt";
  if (c == 2)
if (d
|| __builtin_strcmp(file, "file123.txt")
|| __builtin_strcmp(file2, "file123.txt")
   )
  e = 2;
}

With "gcc -c -O2 -Wstring-compare testcase.c" current trunk shows:

testcase.c: In function 'f':
testcase.c:8:12: warning: '__builtin_strcmp' of a string of length 11 and an
array of size 11 evaluates to nonzero [-Wstring-compare]
8 | || __builtin_strcmp(file2, "file123.txt")
  |^~

There is no warning for line 7 ('file').
Maybe the warning could also be a bit more verbose when the information is
available, like for example:

warning: '__builtin_strcmp' of a string ('file2' with content "y" ||
"file12.txt") and an array ("file123.txt") of size 11 always evaluates to
nonzero [-Wstring-compare]

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

2020-06-19 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673

Martin Sebor  changed:

   What|Removed |Added

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

[Bug middle-end/95673] missing -Wstring-compare for an impossible strncmp test

2020-06-19 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95673

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|regression  |middle-end
 Resolution|INVALID |---
 Ever confirmed|0   |1
   Last reconfirmed||2020-06-19
Summary|Inconsistent optimization   |missing -Wstring-compare
   |behavior when there is a|for an impossible strncmp
   |buffer overflow |test
 Status|RESOLVED|NEW

--- Comment #4 from Martin Sebor  ---
Let me repurpose this bug to track the missing warning then.