On 05/23/2018 08:57 AM, Jeff Law wrote:
On 05/10/2018 04:05 PM, Marc Glisse wrote:
On Thu, 10 May 2018, Martin Sebor wrote:
Can you please comment/respond to Jeff's question below and
confirm whether my understanding of the restriction (below)
is correct?
I don't remember it at all, I really should have expanded that comment...
The documentation of nonzero_chars seems to indicate that, unless
full_string_p, it is only a lower bound on the length of the string, so
not suitable for this kind of alias check. I don't know if we also have
easy access to some upper bound.
(I noticed while looking at this pass that it could probably use
POINTER_DIFF_EXPR more)
So ISTM that we'd need to guard the code that uses si->nonzero_chars in
maybe_invalidate to also check FULL_STRING_P since it appears we're
using si->nonzero_chars as a string length.
I'm not sure I see why. Can you explain?
Here's my explanation of the current approach. si->nonzero_chars
is the lower bound on si's length. maybe_invalidate() invalidates
the string length which is only necessary when something overwrites
one of the first si->nonzero_chars of the array. It doesn't matter
whether si is nul-terminated at that point.
The difference can be seen on the following test case which gets
optimized as I would expect only if full_string_p is not considered,
else the (minimum) string length is invalidated by the assignment
to a.b because full_string_p is false.
struct A {
char a[9];
int b;
};
void f (void)
{
struct A a;
__builtin_memcpy (a.a, "1234", 4);
a.b = 0; // <<< maybe_invalidate()
a.a[4] = 0;
if (__builtin_strlen (a.a) != 4)
__builtin_abort ();
}
Martin
