https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86914
Martin Sebor <msebor at gcc dot gnu.org> 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 gnu.org
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 gnu.org> ---
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.
