The calls to memcpy in both functions either very likely or certainly overflow the destination yet they are not diagnosed. At least in the simple cases when the size of the destination (or source) object is known sufficiently early, before the calls are transformed to MEM_REF, the overflow could be diagnosed. $ cat x.c && gcc -O2 -S -Wall -fdump-tree-gimple=/dev/stdout x.c char a[8]; void f (int i, const void *p) { // overflow very likely __builtin_memcpy (a + i, p, sizeof a); // missing -Wstringop-overflow } void g (unsigned i, const void *p) { // overflow certain if (i) __builtin_memcpy (a + i, p, sizeof a); // missing -Wstringop-overflow } f (int i, const void * p) { _1 = (sizetype) i; _2 = &a + _1; __builtin_memcpy (_2, p, 8); } g (unsigned int i, const void * p) { if (i != 0) goto <D.1916>; else goto <D.1917>; <D.1916>: _1 = (sizetype) i; _2 = &a + _1; __builtin_memcpy (_2, p, 8); <D.1917>: }
Thanks to r279392 GCC 10 detects the certain overflow in g: pr88441.c: In function ‘g’: pr88441.c:13:5: warning: writing 8 bytes into a region of size 7 [-Wstringop-overflow=] 13 | __builtin_memcpy (a + i, p, sizeof a); // missing -Wstringop-overflow | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ pr88441.c:1:6: note: at offset 0 to object ‘a’ with size 8 declared here 1 | char a[8]; | ^ It feels like a separate question whether the possible/likely overflow should also be diagnosed when it's not certain. Diagnosing it would be a design change for the overflow warnings that are currently meant to trigger for certain overflows, so I'm going to resolve this as fixed.