[Bug other/103121] New: Warnings

[Bug other/103121] New: Warnings

[danglin at gcc dot gnu.org]

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

            Bug ID: 103121
           Summary: Warnings
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
              Host: hppa*-*-linux*
            Target: hppa*-*-linux*
             Build: hppa*-*-linux*

/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-12/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
 -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -fno-checking -DIN_GCC 
   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -Icp
-I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o cp/optimize.o -MT
cp/optimize.o -MMD -MP -MF cp/.deps/optimize.TPo ../../gcc/gcc/cp/optimize.c
/home/dave/gnu/gcc/objdir/./prev-gcc/xg++
-B/home/dave/gnu/gcc/objdir/./prev-gcc/
-B/home/dave/opt/gnu/gcc/gcc-12/hppa-linux-gnu/bin/ -nostdinc++
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-B/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include/hppa-linux-gnu
 -I/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/include 
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/src/.libs
-L/home/dave/gnu/gcc/objdir/prev-hppa-linux-gnu/libstdc++-v3/libsupc++/.libs 
-fno-PIE -c  -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -fno-checking -DIN_GCC 
   -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag
-Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -Werror   -DHAVE_CONFIG_H -I. -Icp
-I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include
-I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libcody 
-I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../gcc/gcc/../libbacktrace   -o cp/parser.o -MT
cp/parser.o -MMD -MP -MF cp/.deps/parser.TPo ../../gcc/gcc/cp/parser.c
../../gcc/gcc/cp/optimize.c: In function 'tree_node* cdtor_comdat_group(tree,
tree)':
../../gcc/gcc/cp/optimize.c:208:17: error: writing 1 byte into a region of size
0 [-Werror=stringop-overflow=]
  208 |   grp_name[idx] = '\0';
      |   ~~~~~~~~~~~~~~^~~~~~
In file included from ../../gcc/gcc/system.h:706,
                 from ../../gcc/gcc/cp/optimize.c:22:
../../gcc/gcc/../include/libiberty.h:733:36: note: at offset 1 into destination
object of size 1 allocated by '__builtin_alloca'
  733 | # define alloca(x) __builtin_alloca(x)
      |                    ~~~~~~~~~~~~~~~~^~~
../../gcc/gcc/../include/libiberty.h:365:40: note: in expansion of macro
'alloca'
  365 | #define XALLOCAVEC(T, N)        ((T *) alloca (sizeof (T) * (N)))
      |                                        ^~~~~~
../../gcc/gcc/cp/optimize.c:191:14: note: in expansion of macro 'XALLOCAVEC'
  191 |   grp_name = XALLOCAVEC (char, IDENTIFIER_LENGTH (complete_name) + 1);
      |              ^~~~~~~~~~
../../gcc/gcc/cp/parser.c: In function 'void
cp_parser_decl_specifier_seq(cp_parser*, cp_parser_flags,
cp_decl_specifier_seq*, int*)':
../../gcc/gcc/cp/parser.c:15847:55: warning: misspelled term 'decl' in format;
use 'declaration' instead [-Wformat-diag]
15847 |                     "standard attributes in middle of
decl-specifiers");
      |                                                       ^~~~
../../gcc/gcc/cp/parser.c:15849:57: warning: misspelled term 'decl' in format;
use 'declaration' instead [-Wformat-diag]
15849 |                   "standard attributes must precede the decl-specifiers
to "
      |                                                         ^~~~
cc1plus: all warnings being treated as errors
make[3]: *** [Makefile:1138: cp/optimize.o] Error 1

[Bug other/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=103107
           Keywords|                            |build
   Target Milestone|---                         |12.0
            Summary|Warnings                    |[12 Regression] Warnings in
                   |                            |cp/optimize.c causing build
                   |                            |failure

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
  grp_name = XALLOCAVEC (char, IDENTIFIER_LENGTH (complete_name) + 1);

so the array is at least of size 1.  David, can you try adding
-fno-tree-vectorize to the command line to see if that silences the diagnostic?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2021-11-08 4:24 a.m., rguenth at gcc dot gnu.org wrote:
> David, can you try adding
> -fno-tree-vectorize to the command line to see if that silences the diagnostic?
It does not silence the diagnostic.

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-11-08
             Status|UNCONFIRMED                 |WAITING

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
Can you please attach a preprocessed translation unit that reproduces the
warning?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin <danglin at gcc dot gnu.org> ---
Created attachment 51748
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51748&action=edit
Preprocessed source

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
I can reproduce the warning.  It triggers for the store to *_23 in BB 13 below
(dumped by debug_ranger()), where _23 is the result of the alloca() call in BB
4 plus some offset.  In BB 4, ranger sees two ranges for the alloca argument
_4: [0, 0][2, +INF] on the edge 4->16, and [1, 1] on 4->12.  4->12 dead-ends in
BB 14 with a call to fancy_abort(), so the edge that leads to BB 13 is 4->16. 
But when we ask in BB 4 for _4's range we get VR_RANGE [1, 1].  That doesn't
seem right.  Without any guidance as to which edge I'm interested in I'd expect
to either get the union of the two ranges, [0, +INF].

=========== BB 4 ============
Imports: _1  
Exports: _1  
_1      unsigned int VARYING
Equivalence set : [_1, _2]
Relational : (_4 != _1)
    <bb 4> [local count: 118111600]:
    _4 = _1 + 1;
    grp_name_37 = __builtin_alloca (_4);
    p_38 = _32->identifier.id.str;
    q_39 = _35->identifier.id.str;
    if (_1 != 0)
      goto <bb 16>; [89.00%]
    else
      goto <bb 12>; [11.00%]

grp_name_37 : char * [1B, +INF]
4->16  (T) _1 :         unsigned int [1, +INF]
4->16  (T) _4 :         unsigned int [0, 0][2, +INF]
4->12  (F) _1 :         unsigned int [0, 0]
4->12  (F) _4 :         unsigned int [1, 1]

=========== BB 13 ============
Imports: diff_seen_24  
Exports: diff_seen_24  
diff_seen_24    bool VARYING
idx_47  size_t [1, +INF]
Relational : (_22 <= idx_47)
    <bb 13> [local count: 105119324]:
    _23 = grp_name_37 + idx_47;
    *_23 = 0;
    if (diff_seen_24 != 0)
      goto <bb 15>; [100.00%]
    else
      goto <bb 14>; [0.00%]

_23 : char * [1B, +INF]
13->14  (F) diff_seen_24 :      bool [0, 0]
13->15  (T) diff_seen_24 :      bool [1, 1]

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org

--- Comment #6 from Martin Sebor <msebor at gcc dot gnu.org> ---
The full IL for the function is below:

union tree_node * cdtor_comdat_group (union tree_node * complete, union
tree_node * base)
{
  size_t idx;
  bool diff_seen;
  const char * q;
  const char * p;
  char * grp_name;
  unsigned int _1;
  unsigned int _2;
  bool _3;
  unsigned int _4;
  char _6;
  char _8;
  bool _10;
  bool _11;
  char _14;
  unsigned char _15;
  unsigned char _16;
  bool _17;
  bool _19;
  bool _20;
  unsigned int _22;
  char * _23;
  const char * _26;
  union tree_node * _32;
  union tree_node * _35;
  union tree_node * _42;
  bool _50;
  bool _55;
  bool _56;

  <bb 2> [local count: 118111600]:
  _32 = decl_assembler_name (complete_30(D));
  _35 = decl_assembler_name (base_33(D));
  _1 = _32->identifier.id.len;
  _2 = _35->identifier.id.len;
  if (_1 != _2)
    goto <bb 3>; [0.00%]
  else
    goto <bb 4>; [100.00%]

  <bb 3> [count: 0]:
  fancy_abort ("../../gcc/gcc/cp/optimize.c", 189, "cdtor_comdat_group");

  <bb 4> [local count: 118111600]:
  _4 = _1 + 1;
  grp_name_37 = __builtin_alloca (_4);
  p_38 = _32->identifier.id.str;
  q_39 = _35->identifier.id.str;
  if (_1 != 0)
    goto <bb 16>; [89.00%]
  else
    goto <bb 12>; [11.00%]

  <bb 16> [local count: 105119324]:

  <bb 5> [local count: 955630225]:
  # diff_seen_54 = PHI <diff_seen_24(17), 0(16)>
  # idx_58 = PHI <idx_47(17), 0(16)>
  _6 = MEM[(const char *)p_38 + idx_58 * 1];
  _8 = MEM[(const char *)q_39 + idx_58 * 1];
  if (_6 == _8)
    goto <bb 6>; [34.00%]
  else
    goto <bb 7>; [66.00%]

  <bb 6> [local count: 324914280]:
  MEM[(char *)grp_name_37 + idx_58 * 1] = _6;
  goto <bb 11>; [100.00%]

  <bb 7> [local count: 630715945]:
  _10 = idx_58 == 0;
  _11 = _10 | diff_seen_54;
  if (_11 != 0)
    goto <bb 9>; [0.00%]
  else
    goto <bb 8>; [100.00%]

  <bb 8> [local count: 630715945]:
  _26 = p_38 + 4294967295;
  _14 = MEM[(const char *)_26 + idx_58 * 1];
  _15 = (unsigned char) _14;
  _16 = _15 + 189;
  _17 = _16 > 1;
  _19 = _14 != 73;
  _20 = _17 & _19;
  _3 = _6 != 49;
  _56 = _8 != 50;
  _50 = _56 | _3;
  _55 = _50 | _20;
  if (_55 != 0)
    goto <bb 9>; [0.00%]
  else
    goto <bb 10>; [100.00%]

  <bb 9> [count: 0]:
  fancy_abort ("../../gcc/gcc/cp/optimize.c", 199, "cdtor_comdat_group");

  <bb 10> [local count: 630715945]:
  MEM[(char *)grp_name_37 + idx_58 * 1] = 53;

  <bb 11> [local count: 955630225]:
  # diff_seen_24 = PHI <diff_seen_54(6), 1(10)>
  idx_47 = idx_58 + 1;
  _22 = _32->identifier.id.len;
  if (_22 > idx_47)
    goto <bb 17>; [89.00%]
  else
    goto <bb 13>; [11.00%]

  <bb 17> [local count: 850510901]:
  goto <bb 5>; [100.00%]

  <bb 12> [local count: 12992276]:
  *grp_name_37 = 0;
  goto <bb 14>; [100.00%]

  <bb 13> [local count: 105119324]:
  _23 = grp_name_37 + idx_47;
  *_23 = 0;
  if (diff_seen_24 != 0)
    goto <bb 15>; [100.00%]
  else
    goto <bb 14>; [0.00%]

  <bb 14> [count: 0]:
  fancy_abort ("../../gcc/gcc/cp/optimize.c", 209, "cdtor_comdat_group");

  <bb 15> [local count: 118111600]:
  _42 = get_identifier (grp_name_37);
  return _42;

}

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Sebor from comment #5)
> I can reproduce the warning.  It triggers for the store to *_23 in BB 13
> below (dumped by debug_ranger()), where _23 is the result of the alloca()
> call in BB 4 plus some offset.  In BB 4, ranger sees two ranges for the
> alloca argument _4: [0, 0][2, +INF] on the edge 4->16, and [1, 1] on 4->12. 
> 4->12 dead-ends in BB 14 with a call to fancy_abort(), so the edge that
> leads to BB 13 is 4->16.  But when we ask in BB 4 for _4's range we get
> VR_RANGE [1, 1].  That doesn't seem right.  Without any guidance as to which
> edge I'm interested in I'd expect to either get the union of the two ranges,
> [0, +INF].
> 

BB4 doesn't "see" 2 ranges for _4.   It calculates _4 as varying, since _1 is
varying.  You see at the bottom it shows what the value of _4 is on each
outgoing edge.. its [1,1] on edge 4->12 and [0,0][2, +INF] on edge 4->16.  so
if you ask for the range of _4 in any block dominated by one of those edges you
will see the appropriate range.  

Where are you getting VR_RANGE [1,1] from?    If you ask for
  range_of_expr (r, _4, alloca_stmt) 
You should be getting varying.  Thats all it knows at that point.  

Im not sure what you mean by "without any guidance as to  which edge"?  Either
you are asking for the range on an edge, or on a stmt.

If you ask for the range of _4 somewhere in BB13, you should be seeing unsigned
int [0, 0][2, +INF] since thats the value out 4->16 that eventually reaches
BB13.


> =========== BB 4 ============
> Imports: _1  
> Exports: _1  
> _1	unsigned int VARYING
> Equivalence set : [_1, _2]
> Relational : (_4 != _1)
>     <bb 4> [local count: 118111600]:
>     _4 = _1 + 1;
>     grp_name_37 = __builtin_alloca (_4);
>     p_38 = _32->identifier.id.str;
>     q_39 = _35->identifier.id.str;
>     if (_1 != 0)
>       goto <bb 16>; [89.00%]
>     else
>       goto <bb 12>; [11.00%]
> 
> grp_name_37 : char * [1B, +INF]
> 4->16  (T) _1 : 	unsigned int [1, +INF]
> 4->16  (T) _4 : 	unsigned int [0, 0][2, +INF]
> 4->12  (F) _1 : 	unsigned int [0, 0]
> 4->12  (F) _4 : 	unsigned int [1, 1]
> 
> =========== BB 13 ============
> Imports: diff_seen_24  
> Exports: diff_seen_24  
> diff_seen_24	bool VARYING
> idx_47	size_t [1, +INF]
> Relational : (_22 <= idx_47)
>     <bb 13> [local count: 105119324]:
>     _23 = grp_name_37 + idx_47;
>     *_23 = 0;
>     if (diff_seen_24 != 0)
>       goto <bb 15>; [100.00%]
>     else
>       goto <bb 14>; [0.00%]
> 
> _23 : char * [1B, +INF]
> 13->14  (F) diff_seen_24 : 	bool [0, 0]
> 13->15  (T) diff_seen_24 : 	bool [1, 1]

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor <msebor at gcc dot gnu.org> ---
The [1, 1] range comes from a call to qry->range_of_expr (vr, exp, stmt) in in
get_size_range() in pointer-query.cc:

(gdb) p debug(gimple_bb(stmt))
<bb 4> [local count: 118111600]:
_4 = _1 + 1;
grp_name_37 = __builtin_alloca (_4);
p_38 = _32->identifier.id.str;
q_39 = _35->identifier.id.str;
if (_1 != 0)
  goto <bb 16>; [89.00%]
else
  goto <bb 12>; [11.00%]

$3 = void
(gdb) n    
326           max = wi::to_wide (vr.max ());
(gdb) p range_type
$4 = VR_RANGE
(gdb) p debug_tree(vr.min())
 <integer_cst 0x7ffff6da91e0 type <integer_type 0x7ffff78b69d8 size_t> constant
1>
$5 = void
(gdb) p debug_tree(vr.max())
 <integer_cst 0x7ffff6da91e0 type <integer_type 0x7ffff78b69d8 size_t> constant
1>
$6 = void
(gdb) up
#1  0x0000000001513720 in gimple_call_alloc_size (stmt=0x7ffff4c23d80, 
    rng1=0x7fffffffc980, qry=0x7fffffffd8a0)
    at /src/gcc/master/gcc/pointer-query.cc:506
506         if (!get_size_range (qry, size, stmt, r, SR_ALLOW_ZERO |
SR_USE_LARGEST))
(gdb) 
#2  0x000000000151a68c in handle_ssa_name (ptr=0x7ffff4d0ebd0, addr=false, 
    ostype=1, pref=0x7fffffffd230, snlim=..., qry=0x7fffffffd978)
    at /src/gcc/master/gcc/pointer-query.cc:2088
2088          if (gimple_call_alloc_size (stmt, wr, rvals))
(gdb) 
#3  0x000000000151bd4c in compute_objsize_r (ptr=0x7ffff4d0ebd0, 
    stmt=0x7ffff4de2730, addr=false, ostype=1, pref=0x7fffffffd230, 
    snlim=..., qry=0x7fffffffd978)
    at /src/gcc/master/gcc/pointer-query.cc:2380
2380          return handle_ssa_name (ptr, addr, ostype, pref, snlim, qry);
(gdb) 
#4  0x0000000001519e17 in handle_mem_ref (mref=0x7ffff47f8a00, 
    stmt=0x7ffff4de2730, ostype=1, pref=0x7fffffffd230, snlim=..., 
    qry=0x7fffffffd978) at /src/gcc/master/gcc/pointer-query.cc:1976
1976      if (!compute_objsize_r (mrefop, stmt, false, ostype, pref, snlim,
qry))
(gdb) 
#5  0x000000000151b844 in compute_objsize_r (ptr=0x7ffff47f8a00, 
    stmt=0x7ffff4de2730, addr=false, ostype=1, pref=0x7fffffffd230, 
    snlim=..., qry=0x7fffffffd978)
    at /src/gcc/master/gcc/pointer-query.cc:2314
2314          return handle_mem_ref (ptr, stmt, ostype, pref, snlim, qry);
(gdb) 
#6  0x000000000151befc in compute_objsize (ptr=0x7ffff47f8a00, 
    stmt=0x7ffff4de2730, ostype=1, pref=0x7fffffffd230, 
    ptr_qry=0x7fffffffd978) at /src/gcc/master/gcc/pointer-query.cc:2414
2414      if (!compute_objsize_r (ptr, stmt, false, ostype, pref, snlim,
ptr_qry))
(gdb) 
#7  0x000000000192c0df in strlen_pass::maybe_warn_overflow (
    this=0x7fffffffd880, stmt=0x7ffff4de2730, call_lhs=true, 
    len=0x7ffff78ff4e0, si=0x0, plus_one=false, rawmem=false)
    at /src/gcc/master/gcc/tree-ssa-strlen.c:2038
2038      tree destsize = compute_objsize (dest, stmt, ostype, &aref,
&ptr_qry);
(gdb) dg stmt
# .MEM_53 = VDEF <.MEM_36>
*grp_name_37 = 0;
$7 = (gimple *) 0x7ffff4de2730

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

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

--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Sebor from comment #8)
> The [1, 1] range comes from a call to qry->range_of_expr (vr, exp, stmt) in
> in get_size_range() in pointer-query.cc:
>
> (gdb) 
> #7  0x000000000192c0df in strlen_pass::maybe_warn_overflow (
>     this=0x7fffffffd880, stmt=0x7ffff4de2730, call_lhs=true, 
>     len=0x7ffff78ff4e0, si=0x0, plus_one=false, rawmem=false)
>     at /src/gcc/master/gcc/tree-ssa-strlen.c:2038
> 2038	  tree destsize = compute_objsize (dest, stmt, ostype, &aref, &ptr_qry);
> (gdb) dg stmt
> # .MEM_53 = VDEF <.MEM_36>
> *grp_name_37 = 0;
> $7 = (gimple *) 0x7ffff4de2730


and is this not from:

  <bb 12> [local count: 12992276]:
  *grp_name_37 = 0;
  goto <bb 14>; [100.00%]

which means we have taken the branch 4->12 and should expect:

4->12  (F) _1 :         unsigned int [0, 0]
4->12  (F) _4 :         unsigned int [1, 1]

which is exactly what you are getting?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

--- Comment #10 from Martin Sebor <msebor at gcc dot gnu.org> ---
Sorry, I've been having trouble with GDB and so I'm running two GDB sessions
and I have been mixing output from both of them.  I see the warning for the
store to *_23 in BB 13, not for BB 12.  Here's a fresh session as a sanity
check:

$ /build/hppa-unknown-linux-gnu/gcc-master/gcc/xgcc -B
/build/hppa-unknown-linux-gnu/gcc-master/gcc -O2 -S -Wall
-fdump-tree-strlen-details pr103121.ii -wrapper gdb,--args
GNU gdb (GDB) 11.1
...
(gdb) b tree-ssa-strlen.c:2181
Breakpoint 1 at 0x192caed: file /src/gcc/master/gcc/tree-ssa-strlen.c, line
2181.
(gdb) r
Starting program: /ssd/build/hppa-unknown-linux-gnu/gcc-master/gcc/cc1plus
-fpreprocessed pr103121.ii -quiet -dumpbase pr103121.ii -dumpbase-ext .ii -O2
-Wall -fdump-tree-strlen-details -o pr103121.s

Breakpoint 1, strlen_pass::maybe_warn_overflow (this=0x7fffffffd880,
stmt=0x7ffff4de2730, call_lhs=true, len=1, si=0x0, plus_one=false,
rawmem=false) at /src/gcc/master/gcc/tree-ssa-strlen.c:2181
2181      tree tlen = build_int_cst (size_type_node, len);
(gdb) p debug(gimple_bb(stmt))
<bb 12> [local count: 12992276]:
*grp_name_37 = 0;
goto <bb 14>; [100.00%]

$1 = void
(gdb) c
Continuing.

Breakpoint 1, strlen_pass::maybe_warn_overflow (this=0x7fffffffd880,
stmt=0x7ffff4c2ea00, call_lhs=true, len=1, si=0x0, plus_one=false,
rawmem=false) at /src/gcc/master/gcc/tree-ssa-strlen.c:2181
2181      tree tlen = build_int_cst (size_type_node, len);
(gdb) p debug(gimple_bb(stmt))
<bb 10> [local count: 630715945]:
MEM[(char *)grp_name_37 + idx_58 * 1] = 53;

$2 = void
(gdb) c
Continuing.

Breakpoint 1, strlen_pass::maybe_warn_overflow (this=0x7fffffffd880,
stmt=0x7ffff4c2eb40, call_lhs=true, len=1, si=0x0, plus_one=false,
rawmem=false) at /src/gcc/master/gcc/tree-ssa-strlen.c:2181
2181      tree tlen = build_int_cst (size_type_node, len);
(gdb) p debug(gimple_bb(stmt))
<bb 13> [local count: 105119324]:
_23 = grp_name_37 + idx_47;
*_23 = 0;
if (diff_seen_24 != 0)
  goto <bb 15>; [100.00%]
else
  goto <bb 14>; [0.00%]

$3 = void
(gdb) c
Continuing.
../../gcc/gcc/cp/optimize.c: In function 'tree_node* cdtor_comdat_group(tree,
tree)':
../../gcc/gcc/cp/optimize.c:208:17: warning: writing 1 byte into a region of
size 0 [-Wstringop-overflow=]
../../gcc/gcc/cp/optimize.c:191:40: note: at offset 1 into destination object
of size 1 allocated by '__builtin_alloca'
[Inferior 1 (process 11409) exited normally]

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

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

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Sebor from comment #10)
> Sorry, I've been having trouble with GDB and so I'm running two GDB sessions
> and I have been mixing output from both of them.  I see the warning for the
> store to *_23 in BB 13, not for BB 12.  Here's a fresh session as a sanity
> check:
> 
> 
> Breakpoint 1, strlen_pass::maybe_warn_overflow (this=0x7fffffffd880,
> stmt=0x7ffff4c2eb40, call_lhs=true, len=1, si=0x0, plus_one=false,
> rawmem=false) at /src/gcc/master/gcc/tree-ssa-strlen.c:2181
> 2181	  tree tlen = build_int_cst (size_type_node, len);
> (gdb) p debug(gimple_bb(stmt))
> <bb 13> [local count: 105119324]:
> _23 = grp_name_37 + idx_47;
> *_23 = 0;
> if (diff_seen_24 != 0)
>   goto <bb 15>; [100.00%]
> else
>   goto <bb 14>; [0.00%]
> 
> $3 = void
> (gdb) c
> Continuing.
> ../../gcc/gcc/cp/optimize.c: In function 'tree_node*
> cdtor_comdat_group(tree, tree)':
> ../../gcc/gcc/cp/optimize.c:208:17: warning: writing 1 byte into a region of
> size 0 [-Wstringop-overflow=]
> ../../gcc/gcc/cp/optimize.c:191:40: note: at offset 1 into destination
> object of size 1 allocated by '__builtin_alloca'
> [Inferior 1 (process 11409) exited normally]

Im still not sure what you are asking, or think is wrong.  I don't see any
ranges here.  Presumably the range of _4 is [0,0][2,+INF] at this point since
we've take the other branch.

If you haven't switched to multi-ranges and are still using value_range, then
presumably you would see ~[1,1]

Which means its possible that _4 was 0 on this branch, which also means the
warning would trigger?

The way the IL reads, if _1 is MAX_INT, then _4 is 0, and that gets through on
the 4->16 edge...

Am I missing something?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

--- Comment #12 from Martin Sebor <msebor at gcc dot gnu.org> ---
Okay, here's my question: when I call range_of_expr (vr, _4, stmt) with stmt
being 'grp_name_37 = __builtin_alloca (_4)' in BB 4, should I not expect the
result to be either VR_VARYING or [0, +INF]?

What I think is wrong is that the result is VR_RANGE [1, 1].  That is true in
BB 12 but I did not tell ranger that I'm asking about _4 for BB 12 (i.e., the
4->12 edge).  I just asked it about _4 in BB 4.

The result for the BB 12 query actually happens to be cached by the
pointer_query class and retrieved for subsequent queries about pointers used in
other BB's, but those queries are all independent of the path from BB 4 to the
BB they're being made for.  When I disable the caching then the first query
about _4 in BB 4 (made on behalf of BB 12) gives me [1, 1], and the query for
_4 in BB 4 (made on behalf of BB 13) gives me VR_VARYING and the warning
disappears.  The latter is as expected but I don't expect to get a different
range for the same SSA_NAME in the same basic block unless I specify which
outgoing edge I'm interested in.

So what am I missing?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor <msebor at gcc dot gnu.org> ---
Here's a reduced test case that reproduces the problem with an x86_64-linux GCC
in ILP32 mode:

$ cat pr103121.C && gcc -O2 -S -Wall -m32 pr103121.C
typedef typeof (sizeof 0) size_t;

struct tree_node {
  const char *str;
  unsigned len;
};

typedef tree_node *tree;
extern tree get_identifier_with_length (const char *, size_t);
extern tree get_identifier (const char *);
tree decl_assembler_name (tree);

tree cdtor_comdat_group (tree complete, tree base)
{
  tree complete_name = decl_assembler_name (complete);
  tree base_name = decl_assembler_name (base);

  char *grp_name = (char *) __builtin_alloca (complete_name->len + 1);

  const char *p = complete_name->str;
  const char *q = base_name->str;

  size_t i;
  bool diff_seen = false;

  for (i = 0; i < complete_name->len; i++)
    if (p[i] == q[i])
      grp_name[i] = p[i];
    else
      diff_seen = true;

  grp_name[i] = '\0';

  if (!diff_seen)
    __builtin_abort ();

  return get_identifier (grp_name);
}
pr103121.C: In function ‘tree_node* cdtor_comdat_group(tree, tree)’:
pr103121.C:32:15: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   32 |   grp_name[i] = '\0';
      |   ~~~~~~~~~~~~^~~~~~
pr103121.C:18:46: note: at offset 1 into destination object of size 1 allocated
by ‘__builtin_alloca’
   18 |   char *grp_name = (char *) __builtin_alloca (complete_name->len + 1);
      |                             ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~


An annotated ranger dump is below:

;; Function cdtor_comdat_group

=========== BB 2 ============
Imports: _1  
Exports: _1  
Relational : (_2 != _1)
    <bb 2> [local count: 118111600]:
    _20 = decl_assembler_name (complete_18(D));
    _23 = decl_assembler_name (base_21(D));
    _1 = _20->len;
    _2 = _1 + 1;
    grp_name_25 = __builtin_alloca (_2);
    p_26 = _20->str;
    q_27 = _23->str;
    if (_1 != 0)
      goto <bb 10>; [89.00%]
    else
      goto <bb 6>; [11.00%]

grp_name_25 : char * [1B, +INF]
2->10  (T) _1 :         unsigned int [1, +INF]
2->10  (T) _2 :         unsigned int [0, 0][2, +INF]
2->6  (F) _1 :  unsigned int [0, 0]
2->6  (F) _2 :  unsigned int [1, 1]

=========== BB 10 ============
    <bb 10> [local count: 105119324]:


=========== BB 3 ============
Imports: _4  _6  
Exports: _4  _6  
Equivalence set : [_6]
Equivalence set : [_4]
    <bb 3> [local count: 955630225]:
    # i_35 = PHI <i_33(11), 0(10)>
    # diff_seen_38 = PHI <diff_seen_13(11), 0(10)>
    _4 = MEM[(const char *)p_26 + i_35 * 1];
    _6 = MEM[(const char *)q_27 + i_35 * 1];
    if (_4 == _6)
      goto <bb 4>; [34.00%]
    else
      goto <bb 5>; [66.00%]

i_35 : size_t [0, 4294967294]

=========== BB 4 ============
i_35    size_t [0, 4294967294]
Equivalence set : [_4, _6]
    <bb 4> [local count: 324914280]:
    MEM[(char *)grp_name_25 + i_35 * 1] = _4;


=========== BB 5 ============
Imports: _10  i_35  
Exports: _10  i_33  i_35  
         i_33 : i_35(I)  
i_35    size_t [0, 4294967294]
Relational : (i_33 > i_35)
    <bb 5> [local count: 955630225]:
    # diff_seen_13 = PHI <diff_seen_38(4), 1(3)>
    i_33 = i_35 + 1;
    _10 = _20->len;
    if (_10 > i_33)
      goto <bb 11>; [89.00%]
    else
      goto <bb 7>; [11.00%]

i_33 : size_t [1, +INF]
5->11  (T) _10 :        unsigned int [2, +INF]
5->11  (T) i_33 :       size_t [1, 4294967294]
5->11  (T) i_35 :       size_t [0, 4294967293]
5->7  (F) i_33 :        size_t [1, +INF]
5->7  (F) i_35 :        size_t [0, 4294967294]

=========== BB 11 ============
diff_seen_13    bool VARYING
i_33    size_t [1, 4294967294]
Relational : (_10 > i_35)
Relational : (_10 > i_33)
    <bb 11> [local count: 850510901]:
    goto <bb 3>; [100.00%]


=========== BB 6 ============
    <bb 6> [local count: 12992276]:
    *grp_name_25 = 0;
    goto <bb 8>; [100.00%]


=========== BB 7 ============
Imports: diff_seen_13  
Exports: diff_seen_13  
diff_seen_13    bool VARYING
i_33    size_t [1, +INF]
Relational : (_10 <= i_33)
    <bb 7> [local count: 105119324]:
    _11 = grp_name_25 + i_33;  <<< grp_name_25 points to a block of size 1
    *_11 = 0;                  <<< -Wstringop-overflow
    if (diff_seen_13 != 0)
      goto <bb 9>; [100.00%]
    else
      goto <bb 8>; [0.00%]

_11 : char * [1B, +INF]
7->8  (F) diff_seen_13 :        bool [0, 0]
7->9  (T) diff_seen_13 :        bool [1, 1]

=========== BB 8 ============
    <bb 8> [count: 0]:
    __builtin_abort ();


=========== BB 9 ============
    <bb 9> [local count: 118111600]:
    _30 = get_identifier (grp_name_25);
    return _30;

Non-varying global ranges:
=========================:
_11  : char * [1B, +INF]
grp_name_25  : char * [1B, +INF]
i_33  : size_t [1, +INF]
i_35  : size_t [0, 4294967294]

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

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

--- Comment #14 from Andrew Macleod <amacleod at redhat dot com> ---
As near as I can tell, you are calling debug_ranger () to see what ranger could
produce. That routine creates a new ranger and populates it, dumps out the
results, kills the ranger  and returns.

When I put a breakpoint in the code:

2181      tree tlen = build_int_cst (size_type_node, len);
(gdb) c
Continuing.

Breakpoint 1, strlen_pass::maybe_warn_overflow (this=0x7fffffffcec0,
stmt=0x7fffe9f63910, call_lhs=true, len=0x7fffe9f4ed50, si=0x0, plus_one=false,
rawmem=false) at /gcc/master/gcc/gcc/tree-ssa-strlen.c:1998
1998      if (!len || warning_suppressed_p (stmt, OPT_Wstringop_overflow_))
(gdb) p print_gimple_stmt (stderr, stmt, 0 ,0)
*grp_name_25 = 0;
$8 = void
(gdb) enable 2
(gdb) c
Continuing.

Breakpoint 2, vr_values::range_of_expr (this=0x7fffffffcee0, r=...,
expr=0x7fffe9f5d0d8, stmt=0x7fffe9f5b240) at
/gcc/master/gcc/gcc/vr-values.c:182
182       if (!gimple_range_ssa_p (expr))
(gdb) p print_generic_expr (stderr, expr, 0)
_2$9 = void
(gdb) p print_gimple_stmt (stderr, stmt, 0, 0)
grp_name_25 = __builtin_alloca (_2);
$10 = void

So yes, you are asking for the range of _2 at that statement.... but note the
traceback shows you are invoking:
   Breakpoint 2, vr_values::range_of_expr
Which means you aren't using ranger... that callback is into vr_values... which
is the old EVRP engine.

Have you called enable_ranger() to turn it on for your pass?  You should be
seeing gimple-ranger::range_of_expr() in that traceback.
That also explains why when I range --param=ranger-debug=trace I wasn't seeing
any calls in your listing.

Looking deeper, the place where this is called from in get_size_range:

 if (!query)
    query = get_range_query (cfun);

  if (integral)
    {
      value_range vr;

      query->range_of_expr (vr, exp, stmt);


p get_range_query (cfun)
$11 = (range_query *) 0x40d9a80 <global_ranges>
So if you didn't have a range query, it would have picked up global ranges.. 
Looking down the call chain:

#0  vr_values::range_of_expr (this=0x7fffffffcee0, r=..., expr=0x7fffe9f5d0d8,
stmt=0x7fffe9f5b240) at /gcc/master/gcc/gcc/vr-values.c:182
#1  0x000000000163c58c in get_size_range (query=0x7fffffffcee0,
exp=0x7fffe9f5d0d8, stmt=0x7fffe9f5b240, range=0x7fffffffb840, flags=3) at
/gcc/master/gcc/gcc/pointer-query.cc:320
#2  0x000000000163d724 in gimple_call_alloc_size (stmt=0x7fffe9f5b240,
rng1=0x7fffffffbb20, qry=0x7fffffffcee0) at
/gcc/master/gcc/gcc/pointer-query.cc:506
#3  0x0000000001643501 in compute_objsize_r (ptr=0x7fffe9f5d870,
stmt=0x7fffe9f5b240, ostype=1, pref=0x7fffffffc7f0, snlim=...,
qry=0x7fffffffcfb8) at /gcc/master/gcc/gcc/pointer-query.cc:1970
#4  0x000000000164224c in handle_mem_ref (mref=0x7fffe9f6d230,
stmt=0x7fffe9f63910, ostype=1, pref=0x7fffffffc7f0, snlim=...,
qry=0x7fffffffcfb8) at /gcc/master/gcc/gcc/pointer-query.cc:1702
#5  0x0000000001642d63 in compute_objsize_r (ptr=0x7fffe9f6d230,
stmt=0x7fffe9f63910, ostype=1, pref=0x7fffffffc7f0, snlim=...,
qry=0x7fffffffcfb8) at /gcc/master/gcc/gcc/pointer-query.cc:1865
#6  0x00000000016441a9 in compute_objsize (ptr=0x7fffe9f6d230,
stmt=0x7fffe9f63910, ostype=1, pref=0x7fffffffc7f0, ptr_qry=0x7fffffffcfb8) at
/gcc/master/gcc/gcc/pointer-query.cc:2154
#7  0x0000000001a71634 in strlen_pass::maybe_warn_overflow
(this=0x7fffffffcec0, stmt=0x7fffe9f63910, call_lhs=true, len=0x7fffe9f4ed50,
si=0x0, plus_one=false, rawmem=false)
    at /gcc/master/gcc/gcc/tree-ssa-strlen.c:2038

I see you are passing this range_query down the call chain from the
maybe_warn_overflow.  I am not sure where you picked up a vr-values range
query...   but if you had simply called enable_ranger() at the start of the
pass, and let cfun->get_range_query() get the query object in get_size_range(),
I would expect you to see rangers results.  As it is, I don't know what you are
looking at, nor where it came from.

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

--- Comment #15 from Martin Sebor <msebor at gcc dot gnu.org> ---
The call is made from the strlen pass which still does apparently use EVRP.  I
believe Aldy's been moving it away from it (some of his changes are still
pending) as have I, so things are still in flux.  I don't know the exact status
but I didn't expect I'd get the wrong result from EVRP, just less accurate than
with ranger.  I also didn't realize that debug_ranger() didn't show me the same
ranges I get from a call range_of_expr().  Live and learn I guess.  In any
case, short of finishing the strlen migration to ranger I don't see what can be
done to avoid the warning in this case.

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[aldyh at gcc dot gnu.org]

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

--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---

> $3 = void
> (gdb) n    
> 326	      max = wi::to_wide (vr.max ());
> (gdb) p range_type
> $4 = VR_RANGE
> (gdb) p debug_tree(vr.min())
>  <integer_cst 0x7ffff6da91e0 type <integer_type 0x7ffff78b69d8 size_t>
> constant 1>
> $5 = void
> (gdb) p debug_tree(vr.max())
>  <integer_cst 0x7ffff6da91e0 type <integer_type 0x7ffff78b69d8 size_t>
> constant 1>
> $6 = void

Do not look at min/max.  These have been deprecated for almost a year and a
half.  I've mention this before.  Similarly for range_type.  All these methods
are deprecated:

  // Deprecated legacy public methods.
  enum value_range_kind kind () const;          // DEPRECATED
  tree min () const;                            // DEPRECATED
  tree max () const;                            // DEPRECATED
  bool symbolic_p () const;                     // DEPRECATED
  bool constant_p () const;                     // DEPRECATED
  void normalize_symbolics ();                  // DEPRECATED
  void normalize_addresses ();                  // DEPRECATED
  bool may_contain_p (tree) const;              // DEPRECATED
  void set (tree);                              // DEPRECATED
  bool equal_p (const irange &) const;          // DEPRECATED
  void union_ (const class irange *);           // DEPRECATED
  void intersect (const irange *);              // DEPRECATED

To dump a range you can do:

(gdb) p debug(vr)

And really, you shouldn't be using value_range, but int_range<NN>.  You should
really convert your code to multi-ranges.  Using value_range is asking for
trouble.

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[aldyh at gcc dot gnu.org]

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

--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Martin Sebor from comment #15)

> accurate than with ranger.  I also didn't realize that debug_ranger() didn't
> show me the same ranges I get from a call range_of_expr().  Live and learn I

When I pointed you at it, I mentioned it was only a debugging aid you should
use to look at for reference:

"BTW, debug_ranger() tells you everything ranger would know for the
given IL.  It's meant as a debugging aid.  You may want to look at
it's source to see how it calls the ranger."

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[rguenth at gcc dot gnu.org]

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

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
The EVRP range_of_expr is not context sensitive and if EVRP is in effect the
EVRP active context is implicitely used, so when you try to ask for a different
context you won't get that contexts result but the active one which might
appear as "wrong result".

Not sure if that happens here but that's my guess.  And no, the EVRP
range_of_expr shouldn't return "wrong" results - but you can't ask it for
a context (the 'stmt' argument).

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #19 from Richard Biener <rguenth at gcc dot gnu.org> ---
We definitely need to understand what the code does wrong in using EVRP+ranger,
thus P1.

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

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

--- Comment #20 from Andrew Macleod <amacleod at redhat dot com> ---
I think the anaylsis in comment 5 and onward needs to be redone since it was
using rangers debug output to see something wrong,  but the pass isn't even
using ranger.. It is using EVRP as we determined in comments 14 and 15.. 

So I do not know where this stands, I don't think ranger is even involved?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[rguenther at suse dot de]

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

--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 18 Jan 2022, amacleod at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> 
> --- Comment #20 from Andrew Macleod <amacleod at redhat dot com> ---
> I think the anaylsis in comment 5 and onward needs to be redone since it was
> using rangers debug output to see something wrong,  but the pass isn't even
> using ranger.. It is using EVRP as we determined in comments 14 and 15.. 
> 
> So I do not know where this stands, I don't think ranger is even involved?

The ranger API is, which gives the caller the possibility to pass in
a "context" stmt.  But with EVRP you can only ever query the "actual"
context (the BB the domwalk currently is processing), since global
ranges are adjusted.  If you ever ask for a different context you
will get wrong answers.

So maybe the ranger API needs to be adjusted to ICE whenever the context
is not the current one in case EVRP is active (not sure if it even knows
about the EVRP domwalk).

Or using the ranger APIs should be forbidden when the EVRP domwalk is
active (or the EVRP domwalk needs to be instructed to not adjust
global ranges - IIRC we had a switch for that somewhere).

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

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

--- Comment #22 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to rguenther@suse.de from comment #21)
> On Tue, 18 Jan 2022, amacleod at redhat dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> > 
> > --- Comment #20 from Andrew Macleod <amacleod at redhat dot com> ---
> > I think the anaylsis in comment 5 and onward needs to be redone since it was
> > using rangers debug output to see something wrong,  but the pass isn't even
> > using ranger.. It is using EVRP as we determined in comments 14 and 15.. 
> > 
> > So I do not know where this stands, I don't think ranger is even involved?
> 
> The ranger API is, which gives the caller the possibility to pass in
> a "context" stmt.  But with EVRP you can only ever query the "actual"
> context (the BB the domwalk currently is processing), since global
> ranges are adjusted.  If you ever ask for a different context you
> will get wrong answers.
> 
> So maybe the ranger API needs to be adjusted to ICE whenever the context
> is not the current one in case EVRP is active (not sure if it even knows
> about the EVRP domwalk).
> 
> Or using the ranger APIs should be forbidden when the EVRP domwalk is
> active (or the EVRP domwalk needs to be instructed to not adjust
> global ranges - IIRC we had a switch for that somewhere).

The EVRP implementation of range_of_expr() might be able to verify that the
context is correct at the time of the call and trap. I'll have a look. 

I'm not convinced that is whats at play here tho. Unless new code was added to
the pass to use ranger and it's API without actually converting it to ranger?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[rguenther at suse dot de]

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

--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 19 Jan 2022, amacleod at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> 
> --- Comment #22 from Andrew Macleod <amacleod at redhat dot com> ---
> (In reply to rguenther@suse.de from comment #21)
> > On Tue, 18 Jan 2022, amacleod at redhat dot com wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> > > 
> > > --- Comment #20 from Andrew Macleod <amacleod at redhat dot com> ---
> > > I think the anaylsis in comment 5 and onward needs to be redone since it was
> > > using rangers debug output to see something wrong,  but the pass isn't even
> > > using ranger.. It is using EVRP as we determined in comments 14 and 15.. 
> > > 
> > > So I do not know where this stands, I don't think ranger is even involved?
> > 
> > The ranger API is, which gives the caller the possibility to pass in
> > a "context" stmt.  But with EVRP you can only ever query the "actual"
> > context (the BB the domwalk currently is processing), since global
> > ranges are adjusted.  If you ever ask for a different context you
> > will get wrong answers.
> > 
> > So maybe the ranger API needs to be adjusted to ICE whenever the context
> > is not the current one in case EVRP is active (not sure if it even knows
> > about the EVRP domwalk).
> > 
> > Or using the ranger APIs should be forbidden when the EVRP domwalk is
> > active (or the EVRP domwalk needs to be instructed to not adjust
> > global ranges - IIRC we had a switch for that somewhere).
> 
> The EVRP implementation of range_of_expr() might be able to verify that the
> context is correct at the time of the call and trap. I'll have a look. 
> 
> I'm not convinced that is whats at play here tho. Unless new code was added to
> the pass to use ranger and it's API without actually converting it to ranger?

Well, I don't see where EVRP ever had range_of_expr (), so that's clearly
a ranger API and thus if the pass is using that and passing in a context
that is asking for trouble.

But from a quick look we're only passing down the stmt we're currently
analyzing and ultimatively process via strlen_pass::before_dom_children.

Unless pointer-query.cc somehow changes 'stmt' or does caching based
on only SSA names, not including the 'stmt' context they were produced.
Indeed the cache is populated with put_ref which doesn't have any
'stmt' context but an SSA name only.  Martin?  It seems some
queries computing the cached size use the 'stmt' context of the _use_
but the cache is for definition points?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[rguenth at gcc dot gnu.org]

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

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
Oh, and btw. strlen no longer uses EVRP it seems - it still performs a DOM walk
but is using ranger now (but my guess is still the ptr-query caching is what is
broken - one could try simply bypassing it to see if that fixes the testcase).

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

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

--- Comment #25 from Andrew Macleod <amacleod at redhat dot com> ---
OK, lets reset. 

I run it now, and ranger is indeed being used, so somewhere along the way the
conversion was finished I guess.

so.

looking at the trace, I see:

446      range_of_expr(_2) at stmt grp_name_25 = __builtin_alloca (_2);
447        range_of_stmt (_2) at stmt _2 = _1 + 1;
448          ROS dependence fill
               ROS dep fill (_2) at stmt _2 = _1 + 1;
             FALSE : (448) ROS  (_2)
449          range_of_expr(_1) at stmt _2 = _1 + 1;
450            range_of_stmt (_1) at stmt _1 = _20->len;
               TRUE : (450) range_of_stmt (_1) unsigned int VARYING
             TRUE : (449) range_of_expr (_1) unsigned int VARYING
 Registering value_relation (_2 != _1) (bb2) at _2 = _1 + 1;
           TRUE : (447) range_of_stmt (_2) unsigned int VARYING
         TRUE : (446) range_of_expr (_2) unsigned int VARYING

So the call to __builtin_alloca is returning VARYING, as one would expect.
The original comment#12 from martin was asking that he was seeing [1,1] instead
of VARYING for _4 (which is now _2 in this listing I presume)

That query should be returning VARYING now, as expected.

I also don't get the warning anymore on trunk.

Is there still an issue here?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

--- Comment #26 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #25)
...
> I also don't get the warning anymore on trunk.
> 
> Is there still an issue here?

The strlen pass was converted to Ranger in
g:6b8b959675a3e14cfdd2145bd62e4260eb193765.  I also don't see the warning on
trunk with an hppa-linux cross so I think this can be resolved once John David
confirms.


(In reply to rguenther@suse.de from comment #23)
...
The cache stores the offset of the pointer SSA_NAME at its definition.  Since
the SSA_NAME never changes, the context doesn't matter.  Or am I missing
something?

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #27 from John David Anglin <danglin at gcc dot gnu.org> ---
Warnings are gone.

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[rguenther at suse dot de]

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

--- Comment #28 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 20 Jan 2022, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121
> 
> --- Comment #26 from Martin Sebor <msebor at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #23)
> ...
> The cache stores the offset of the pointer SSA_NAME at its definition.  Since
> the SSA_NAME never changes, the context doesn't matter.  Or am I missing
> something?

Consider

  ptr_1 = &a + _2;
  if (_2 == 0)
    use1 (ptr_1);
  use2 (ptr_1);

if we visit use1 and ask ptr-query for ptr_1 with context 'use1' I
expect it to record offset 0 (_2 == 0) from &a at the ptr_1 definition
in the cache.  When we then proceed to use2 and ask ptr-query for ptr_1
with context 'use2' it will find the cached &a + 0, won't it?  And
that would be wrong here.

But as said I only briefly looked at how things work but it does
seem that the ability to specify a context to ptr_query but caching
things for SSA definitions with query results which use those context
can lead to wrong answers down the road.

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

--- Comment #29 from Martin Sebor <msebor at gcc dot gnu.org> ---
>From memory: At use1 the cache is empty so go and find its definition and
record the offset at that point, with the pointer addition as the context.  And
at use2 we look up the same offset.  So use1 won't reflect the constant offset.
 That could be both good (if the code is unreachable) and bad (if it is and the
use is invalid.

If it did work the way you're concerned I'd expect to see a lot of mysterious
false positives.  The cache has been in use since GCC 11 and I don't recall
coming across any puzzling problems.  But we have seen an uptick in false
positives in GCC 12 after we switched over to Ranger so let me double check it
really does work the way I say it does.

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[amacleod at redhat dot com]

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

--- Comment #30 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Martin Sebor from comment #29)
> From memory: At use1 the cache is empty so go and find its definition and
> record the offset at that point, with the pointer addition as the context. 
> And at use2 we look up the same offset.  So use1 won't reflect the constant
> offset.  That could be both good (if the code is unreachable) and bad (if it
> is and the use is invalid.
> 
> If it did work the way you're concerned I'd expect to see a lot of
> mysterious false positives.  The cache has been in use since GCC 11 and I
> don't recall coming across any puzzling problems.  But we have seen an
> uptick in false positives in GCC 12 after we switched over to Ranger so let
> me double check it really does work the way I say it does.

  ptr_1 = &a + _2;
  if (_2 == 0)
    use1 (ptr_1);
  use2 (ptr_1);

If you call ranger and ask for the _2 range and provide the context as stmt
"use1 (ptr_1)",  It will certainly return [0, 0].  ... because you are asking
for the range of _2 at that point.

If you then cache that that would be wrong.  So if you are "visiting" the
definition for the first time, you would want to provide the DEF_STMT as the
context... You want to know the range of _2 is at the DEF point of ptr_1, not
the use point later on.    Then you will get whatever _2 is at the def point
which is probably varying at this point. 

just to be aware..

[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure

[msebor at gcc dot gnu.org]

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

--- Comment #31 from Martin Sebor <msebor at gcc dot gnu.org> ---
I believe I understand what both of you are saying and (also) that the cache
behaves correctly.  It stores offsets based on the pointer definition
statements.  Here's a test that I think reproduces the conditions you describe,
along with a dump of the access pass.  The cache contents show the offset has
the range [0, 3] (negative offsets are invalid and so they were eliminated, as
were offsets in excess of 3).  Stepping through the pointer_query code shows
that the offset cached for the p_6 pointer is derived from the 'p_6 = &a + _1;'
statement.

(The duplicate pointer_query cache contents (again) dump is a bug that I should
fix.)

Let me know if I misunderstood something.

$ cat x.c && gcc -O2 -S -fdump-tree-waccess3-details=/dev/stdout x.c
char a[3];

void g (int i, const void *s, int n)
{
  int j = i + 1;

  char *p = a + j;

  if (j == 7)
    __builtin_memcpy (p, s, n);

  __builtin_memset (p, 0, 3);
}

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

 Registering value_relation (j_5 > i_4(D)) (bb2) at j_5 = i_4(D) + 1;
pointer_query counters:
  index cache size:   19
  index entries:      2
  access cache size:  4
  access entries:     2
  hits:               1
  misses:             2
  failures:           0
  max_depth:          1

pointer_query cache contents:
  6.0[3]: p_6 = &a + [0, 3] (base0); size: 3
  9.0[1]: s_9(D) = s_9(D); size: unknown


pointer_query cache contents (again):
  6.0: p_6 = &a + [0, 3] (base0); size: 3
  9.0: s_9(D) = s_9(D); size: unknown
void g (int i, const void * s, int n)
{
  char * p;
  int j;
  sizetype _1;
  long unsigned int _2;

  <bb 2> [local count: 1073741824]:
  j_5 = i_4(D) + 1;
  _1 = (sizetype) j_5;
  p_6 = &a + _1;
  if (j_5 == 7)
    goto <bb 3>; [20.24%]
  else
    goto <bb 4>; [79.76%]

  <bb 3> [local count: 217325344]:
  _2 = (long unsigned int) n_8(D);
  __builtin_memcpy (p_6, s_9(D), _2);

  <bb 4> [local count: 1073741824]:
  __builtin_memset (p_6, 0, 3); [tail call]
  return;

}