https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109609
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #10)
> On the first testcase reverting the offending rev. shows that it causes
>
> <bb 2> [local count: 137085152]:
> - MEM[(char *)&buf + 12B] = 0;
> - _19 = *id_8(D);
> - if (_19 != 0)
> + _18 = *id_7(D);
> + if (_18 != 0)
>
> thus we DSE the store to the end.
>
> The issue is that the fnspec we have for strncpy says the access size
> is specified by argument 3 but what it specified there is the _maximum_
> size read, not the actual size. So instead of "1cO313" it should be
> "1cO31 " ('1' is somewhat odd then, it says we copy 'src' to 'dst'
> but we only say the 'dst' write covers arg 3 size - I guess that's OK
> for points-to analysis, the additional zeros written do not have pointers,
> but if we use it differently it might be a wrong spec?)
>
> I'm scanning other builtins for similar issues.
Note a different fix would be to re-interpret the case of reads and
say the size is _up to_ the specified length, thus use
ao_ref_init_from_ptr_and_range instead of _and_size.
strncat, stpncpy, strncmp, strnlen, strndup are affected similarly.
for functions like memchr I'm not sure if we can assume all 'n' bytes are
read (thus if that would cause known overread -> undefined behavior).
Honza? Any opinion?
Fix for the testcase, but incomplete as noted above:
diff --git a/gcc/builtins.cc b/gcc/builtins.cc
index 0e06fa5b2e0..133707c1617 100644
--- a/gcc/builtins.cc
+++ b/gcc/builtins.cc
@@ -11562,11 +11562,12 @@ builtin_fnspec (tree callee)
case BUILT_IN_STPCPY_CHK:
return ".cO 1 ";
case BUILT_IN_STRNCPY:
+ case BUILT_IN_STRNCPY_CHK:
+ return "1cO31 ";
case BUILT_IN_MEMCPY:
case BUILT_IN_MEMMOVE:
case BUILT_IN_TM_MEMCPY:
case BUILT_IN_TM_MEMMOVE:
- case BUILT_IN_STRNCPY_CHK:
case BUILT_IN_MEMCPY_CHK:
case BUILT_IN_MEMMOVE_CHK:
return "1cO313";
