[Bug tree-optimization/84383] [8 Regression] ICE in maybe_diag_stxncpy_trunc

2018-02-15 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84383

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/84383] [8 Regression] ICE in maybe_diag_stxncpy_trunc

2018-02-15 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84383

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Feb 15 11:18:47 2018
New Revision: 257684

URL: https://gcc.gnu.org/viewcvs?rev=257684=gcc=rev
Log:
PR tree-optimization/84383
* tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Don't look at
dstoff nor call operand_equal_p if dstbase is NULL.

* gcc.c-torture/compile/pr84383.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr84383.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/84383] [8 Regression] ICE in maybe_diag_stxncpy_trunc

2018-02-14 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84383

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84395,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84396

--- Comment #4 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #2)

Yes, the code isn't perfect.  I think one bug is what you already pointed out
in the -Wrestrict code (bug 84095 comment #1) and that I recently submitted a
fix for.  There may be others.  I just filed bug 84395 for one issue.  I'll see
what other test cases I can come up with and open bugs for the problems I find.

The reference to '\0' in the comment describes the ideal goal I had in mind. 
It might be worth tightening things up to look for a literal zero.  I raised
bug 84396 for this.

[Bug tree-optimization/84383] [8 Regression] ICE in maybe_diag_stxncpy_trunc

2018-02-14 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84383

Jakub Jelinek  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Martin, please look at the above comment.

[Bug tree-optimization/84383] [8 Regression] ICE in maybe_diag_stxncpy_trunc

2018-02-14 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84383

--- Comment #2 from Jakub Jelinek  ---
Created attachment 43415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43415=edit
gcc8-pr84383.patch

Untested fix.

BTW, the code is still problematic, e.g. the:
  if (code == ARRAY_REF || code == MEM_REF)
lhs = TREE_OPERAND (lhs, 0);
For MEM_REF, TREE_OPERAND (lhs, 0) is either ADDR_EXPR of some decl, or an
SSA_NAME, I can understand what you can do with the SSA_NAME (for the stpncpy
result comparison which will also be a SSA_NAME), but other than that it is
then apples vs. oranges e.g. in the get_addr_base_and_unit_offset calls.

Also, the comment says:
  /* Look for dst[i] = '\0'; after the stxncpy() call and if found
 avoid the truncation warning.  */
but you aren't testing for that, but rather that there is any kind of
assignment after the strncpy call (no check that the rhs of the next_stmt is
integer_zerop).

[Bug tree-optimization/84383] [8 Regression] ICE in maybe_diag_stxncpy_trunc

2018-02-14 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84383

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1

--- Comment #1 from Jakub Jelinek  ---
Started with r255031.

[Bug tree-optimization/84383] [8 Regression] ICE in maybe_diag_stxncpy_trunc

2018-02-14 Thread jakub at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84383

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-02-14
   Target Milestone|--- |8.0
 Ever confirmed|0   |1