https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78174
--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> --- The problem can be reduced to the following test case that triggers the warning even with unpatched GCC (and prior releases). $ cat b.c && g++ -O2 -S -Wall b.c struct A { int i, j; }; struct B { int i0, j0, i1, j1, i2, j2, i3, j3, i4, j4; }; struct C { union { struct A a[1]; struct B b; } u; }; struct D: C { }; void f (struct D *d) { struct A *p = &d->u.a[3]; __builtin___memset_chk (p, 0, sizeof *p, __builtin_object_size (p, 1)); } b.c: In function ‘void f(D*)’: b.c:17:73: warning: call to void* __builtin___memset_chk(void*, int, long unsigned int, long unsigned int) will always overflow destination buffer __builtin___memset_chk (p, 0, sizeof *p, __builtin_object_size (p, 1)); ^ Such code is undefined under the C++ (and C) standard rules. (Curiously, GCC doesn't issue the warning for an equivalent function that takes struct C* as an argument.) The same warning is also emitted when the memset call in emit-rtl.c is replaced with a __builtin___memset_chk call corresponding to the one above. The patch that triggers the warning simply enables the same compile-time checking for memset as is done by __builtin___memset_chk with type-1 object size checking. I see that Glibc uses type-0 checking for memset even with _FORTIFY_SOURCE=2, so the patch could either be changed to do the same or enhanced to let users specify the __builtin_object_size checking type, and perhaps even a different type for raw memory functions like memset and for string functions, to make it possible to fine-tune the checking to the state of the code base and avoid issuing warnings for this kind of code in legacy software. I think those would be enhancements worth considering, but I also think that GCC itself should try to avoid relying on undefined behavior. GCC provides zero-length arrays as a substitute for flexible array members. In this case, the array has one (not zero) element. It would be nice if changing it to a zero-element array would let GCC treat it as a flexible array member on steroids so that users would have to opt in to relying on an extension to avoid the warning here, but that's not the case. I realize that GCC sometimes treats even one element arrays (and even bigger if they're last) as zero-length even though that's not documented anywhere (AFAIK), but it would be nice to get away from that.