https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095
--- Comment #7 from Martin Sebor <msebor at gcc dot gnu.org> --- (In reply to Arnd Bergmann from comment #6) > /git/arm-soc/include/linux/string.h:437:10: error: '__builtin_strcpy' > accessing 0 or more bytes at offsets [36, 25] and 446 may overlap up to 0 > bytes at offset [9223372036854775807, -9223372036854775808] This does suggest a bug in checker, similar to one that was fixed for memcpy not too long ago. The offset ranges should be in increasing order (i.e., [25, 36], not the other way around). Internally, they are represented as 128-bit numbers but when they're printed they are converted to 64-bit because GCC doesn't have support for printing anything bigger. The wrong order implies that the first offset crosses the PTRDIFF_MAX boundary (i.e., it's probably a union of two offsets: [36, PTRDIFF_MAX] and [PTRDIFF_MIN, 25]). It's possible that the strcpy checker has the same bug as the memcpy one. They are different because the memcpy checker warns only for definite overlaps and the one for strcpy and other string functions even for possible overlaps. I haven't yet been able to reproduce this in a small test case. I'll keep working on but it would help expedite the fix if you could attach a translation unit that reproduces it. Thanks for your help!
