Re: ToT build error with ToT GCC on Aarch64

[Zach van Rijn <me at zv dot io>]

On Mon, 2018-07-23 at 11:13 -0600, Martin Sebor wrote:
> On 07/23/2018 10:19 AM, Jeff Law wrote:
> > On 07/23/2018 09:51 AM, Steve Ellcey wrote:
> > > I have run into a problem when building the ToT glibc with
> > > the ToT GCC on
> > > Aarch64.  I haven't dug into this enough to know if this is
> > > a GCC problem,
> > > a glibc problem, or just a message that needs to be ignored
> > > but I wanted to
> > > send out an email in case this is something that needs to
> > > be addressed
> > > before GCC 2.28 is released.
> > 
> > Martin S. and I are already looking at this and I've already
> > asked
> > Martin to bring in Carlos and Florian.
> > 
> > Our initial read is that it's a valid warning, but neither of
> > us knows
> > this code, so it's a very preliminary finding.
> 
> I spent some time reducing it to a smaller test case over
> the weekend to better see what's going on here.  My reading
> of the code is below but as Jeff already suggested, having
> someone familiar with it either confirm it or point out what
> I missed would be helpful.
> 
> internal_fnwmatch() has this:
...
>      ...
>      for (cnt = 0; cnt < nhere && cnt < len; ++cnt)
>        if (cp[cnt] != usrc[cnt])   // access (&str + 1)[0]
>           break;
> 
> It looks to me like the first and only iteration of the loop
> accesses (&str + 1)[0].
> 
> Martin
> 
> PS The test case I boiled it down to is attached.

Hi Martin,

I'm not sure if this is the source of the issue, but variable
`c1` is initialized to be zero, so when `nrules` is non-zero AND
the condition -- if (c == L'.' && p[1] == L']') -- is true, then
`c1` remains at zero even during the declaration of array `str`.

...
size_t c1 = 0;
while (1)
{
    c = *++p;
    if (c == L'.'  && p[1] == L']')
    {
        p += 2;
        break;        // [A] below `c1` increment will not occur
    }
    if (c == '\0')
        return 1;
    ++c1;
}
if (nrules == 0)
{
    ...
}
else                  // [B] this branch is usually taken
{
    char str[c1];     // [C] causing this to be `char str[0];`
    ...
}
...

So when [A] and [B], [C] is a problem. This occurs in two places.

ZV