[Bug tree-optimization/86265] Wrong code on an invalid code starting with r255790

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86265

--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 21 Jun 2018, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86265
> 
> --- Comment #4 from Martin Sebor <msebor at gcc dot gnu.org> ---
> Using strncpy or strlen to cross subobject boundaries isn't valid.  GCC catches
> the strncpy bug with -Warray-bounds:
> 
> pr86265.c: In function ‘main’:
> ...
> In file included from /usr/include/string.h:630,
>                  from pr86265.c:2:
> pr86265.c:13:3: warning: ‘__builtin_strncpy’ offset [5, 104] from the object at
> ‘s’ is out of the bounds of referenced subobject ‘data’ with type ‘char[4]’ at
> offset 0 [-Warray-bounds]
>    strncpy(s.data, argv[1], 4 + 100);
>    ^~~~~~~
> 
> Use memcpy (&s, ...) and memchr (&s, ...) to get that effect.  To make it
> strictly valid, be sure to pass to the functions the address of the enclosing
> object rather than a pointer to one of its members:
> 
>   struct S s = { "", "" };
>   memcpy (&s, argv[1], strlen (argv[1]));
>   int length = min((char*)memchr (&s, 0, sizeof s) - (char*)&s, 4);
> 
> (-Warray-bounds lets raw memory functions like memcpy and memchr cross
> subobject boundaries without being diagnosed.)

I believe the warning (and policy like _FORTIFY_SOURCE=n) is simply
a policy deemed good for security reasons.  We may not take advantage
of policy violations in code generation though.