http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59125
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2013-11-14
Component|c |middle-end
Target Milestone|--- |4.8.3
Summary|[4.8 regression] gcc |[4.8/4.9 Regression] gcc
|triggers wrong strncpy_chk |triggers wrong strncpy_chk
Ever confirmed|0 |1
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed. I think we have a similar dup for this that shows the opposite
(missed check).
We CSE the addresses &u.vi[0] and &u.all[0] resulting in
<bb 2>:
_2 = &u_1(D)->D.2172.vi;
__builtin_strncpy (&vi, _2, 8);
_5 = &u_1(D)->D.2172.pi;
__builtin_strncpy (&pi, _5, 16);
_10 = __builtin_object_size (_2, 1);
__builtin___strncpy_chk (_2, "AbcdefghAbcdefghijklmnopAbcd", 28, _10);
and thus object-size computation going havoc. The objsz pass reads
too much into the structure of addresses.
We can mitigate this somewhat by folding object sizes early more aggressively
but in this case, when we don't want to fold to 'unknown' too early (like
for this case, where u->all has unknown size as trailing array), it does not
help (we want to wait for an inlining eventually turing 'u' into the address
of a real object to constrain u->all further).
There are opposite desires at work here - the desires to optimize the
program to get more precise 'objects' and the desire to optimize not too much
to confuse the object size computation.
