On 05/23/2018 01:28 PM, Martin Sebor wrote: > 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. My bad. I was thinking in terms of maximum string length which si->nonzero_chars does not represent unless it's also FULL_STRING_P. A a minimum string length it should be OK.
So OK with a quick comment clarifying that we're using it to compute a minimum string length rather than a maximum string length. Sorry for the goof on my part. jeff
