https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96798
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #6)
> Thanks! The "memset" call has become a call to "__builtin___memset_chk"
> (perhaps due to _FORTIFY_SOURCE, or something similar in Darwin's libc?),
(transitive include of strings.h, for macOS >= 10.5)
usr/include/_types.h:# define _FORTIFY_SOURCE 2 /* on by default */
usr/include/strings.h:
#if defined (__GNUC__) && _FORTIFY_SOURCE > 0 && !defined (__cplusplus)
/* Security checking functions. */
#include <secure/_strings.h>
#endif
secure/_strings.h:
#if _USE_FORTIFY_LEVEL > 0
....
#if __has_builtin(__builtin___memset_chk) || defined(__GNUC__)
#undef bzero
/* void bzero(void *s, size_t n) */
#define bzero(dest, ...) \
__builtin___memset_chk (dest, 0, __VA_ARGS__, __darwin_obsz0
(dest))
#endif
(AFAIR, fort
> and the analyzer doesn't (yet) know about that builtin.
>
> I can reproduce the issue by hacking this into the test:
>
> #define memset(DST, SRC, LEN) \
> __builtin___memset_chk ((DST), (SRC), (LEN), \
> __builtin_object_size((DST), 0))
>
> There are at least two issues here:
> (a) looks like region_model::on_call_pre is erroneously treating a builtin I
> haven't coded yet as a no-op; it should instead conservatively assume that
> any escaped/reachable regions are affected
> (b) the analyzer should handle that builtin (and probably others)
