Martin Sebor <msebor at gcc dot> changed:

           What    |Removed                     |Added
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-08-11
                 CC|                            |law at redhat dot com,
                   |                            |msebor at gcc dot
            Summary|gcc 8.1 -O2 generates wrong |[8/9 Regression] -O2
                   |code with strlen() of       |generates wrong code with
                   |pointers within one-element |strlen() of pointers within
                   |arrays of structures        |one-element arrays of
                   |                            |structures
     Ever confirmed|0                           |1
      Known to fail|                            |8.2.0, 9.0

--- Comment #2 from Martin Sebor <msebor at gcc dot> ---
Confirmed.  Most likely caused by r255790.

The strlen pass sees:

  _1 = &MEM[(void *)p_3(D) + 5B];
  _2 = __builtin_strlen (_1);

The code in maybe_set_strlen_range() tries to avoid using the size of the last
member array (GCC treats all such arrays as flexible array members) by checking
the result of array_at_struct_end_p() but the function doesn't handle MEM_REF
and returns false.  The optimization is disabled if the array is a bona fide
C11 flexible array member because the size of such an array is unknown.

Enhancing array_at_struct_end_p() to deal with MEM_REF or adding an
array_not_at_struct_end_p() that returns a conservative result would fix this
but the strlen range optimization will likely be disabled regardless.

Reply via email to