https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78918
Martin Sebor <msebor at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-06-21
See Also| |https://gcc.gnu.org/bugzill
| |a/show_bug.cgi?id=35503
Ever confirmed|0 |1
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
One reason for the missing warning in the test case in comment #0 is that GCC
built-ins aren't declared using the restrict qualifier. In particular, both
memcpy and memmove are declared in builtins.def like so:
DEF_LIB_BUILTIN_CHKP (BUILT_IN_MEMCPY, "memcpy",
BT_FN_PTR_PTR_CONST_PTR_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF)
DEF_LIB_BUILTIN_CHKP (BUILT_IN_MEMMOVE, "memmove",
BT_FN_PTR_PTR_CONST_PTR_SIZE, ATTR_RET1_NOTHROW_NONNULL_LEAF)
with BT_FN_PTR_PTR_CONST_PTR_SIZE specifying the same signature. BT_PTR
expands to void_ptr_node, with no restrict qualifier.
The second reason is that the -Wrestrict warning is implemented in the
front-end, with no ability to determine relationships between distinct
pointers. So while memcpy(p, p, n) is diagnosed (provided memcpy is declared
restrict), memcpy(p, q, n) is not. That limitation limits the warning to just
the most basic and obvious cases, missing the more interesting problems.
Confirming on that basis. Adding a reference to bug 35503 under which the
warning was implemented (in r242366).
