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?