https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106927
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Keywords| |diagnostic
Ever confirmed|0 |1
CC| |msebor at gcc dot gnu.org
Last reconfirmed| |2022-09-13
Component|c |tree-optimization
Summary|false-positive |false-positive
|-Werror=restrict warnings |-Werror=restrict warnings
|for memmove (calling |for memmove (calling
|memcpy) within array |memcpy) within string
| |literal
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We issue the diagnostic for
__builtin_memcpy ("abcdefghijklmnopqrstuvwxyz012345", &MEM <char[33]> [(void
*)"abcdefghijklmnopqrstuvwxyz012345" + 1B], 31);
but we'd better issue a -Wwrite-strings diagnostic.
The actually emitted diagnostic is indeed somewhat misleading but the
reason is we simplify the memmove call to memcpy as seen above because
we have
if (code == BUILT_IN_MEMMOVE)
{
/* Both DEST and SRC must be pointer types.
??? This is what old code did. Is the testing for pointer types
really mandatory?
If either SRC is readonly or length is 1, we can use memcpy. */
if (!dest_align || !src_align)
return false;
if (readonly_data_expr (src)
|| (tree_fits_uhwi_p (len)
&& (MIN (src_align, dest_align) / BITS_PER_UNIT
>= tree_to_uhwi (len))))
{
tree fn = builtin_decl_implicit (BUILT_IN_MEMCPY);
...
that should probably suppress -Wrestrict on the call?
