Re: Re: ToT build error with ToT GCC on Aarch64

["Andre Vieira (lists)" <Andre dot SimoesDiasVieira at arm dot com>]

On 23/07/18 21:36, Jeff Law wrote:
> On 07/23/2018 02:31 PM, Jeff Law wrote:
>> On 07/23/2018 12:51 PM, Martin Sebor wrote:
>>> On 07/23/2018 12:29 PM, Martin Sebor wrote:
>>>> On 07/23/2018 11:26 AM, Florian Weimer wrote:
>>>>> On 07/23/2018 06:19 PM, 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.
>>>>>
>>>>> Would it be possible to print the full inlining stack for these GCC
>>>>> warnings?  I don't see a %K format specifier (or whatever is used for
>>>>> this).
>>>>>
>>>>> I think it would make it a bit easier to track these down.
>>>>
>>>> It's one of my own pet peeves with the -Warray-bounds warnings
>>>> that they don't do that.  I've quickly hacked GCC to print
>>>> the inlining stack.  It doesn't look to me like it helps that
>>>> much but I'll let you be the judge:
>>>>
>>>> In file included from fnmatch.c:244:
>>>> In function ‘findidxwc’,
>>>>     inlined from ‘internal_fnwmatch’ at fnmatch_loop.c:404:10:
>>>> ../locale/weightwc.h:124:28: warning: array subscript 1 is outside array
>>>> bounds of ‘wint_t[1]’ {aka ‘unsigned int[1]’} [-Warray-bounds]
>>>
>>> Here's a bit more context showing the variable being referenced
>>> (for simplicity, GCC takes singleton objects as arrays of one
>>> element):
>>>
>>> In file included from fnmatch.c:244:
>>> In function ‘findidxwc’,
>>>     inlined from ‘internal_fnwmatch’ at fnmatch_loop.c:404:10:
>>> ../locale/weightwc.h:124:28: error: array subscript 1 is outside array
>>> bounds of ‘wint_t[1]’ {aka ‘unsigned int[1]’} [-Werror=array-bounds]
>>>     if (cp[nhere - 1] > usrc[nhere -1])
>>>                         ~~~~^~~~~~~~~~
>>> In file included from fnmatch.c:315:
>>> fnmatch_loop.c: In function ‘internal_fnwmatch’:
>>> fnmatch_loop.c:342:13: note: while referencing ‘str’
>>>        UCHAR str;
>>>              ^~~
>>>
>>> There's an interesting comment above the declaration:
>>>
>>>     /* It's important that STR be a scalar variable rather
>>>        than a one-element array, because GCC (at least 4.9.2
>>>        -O2 on x86-64) can be confused by the array and
>>>        diagnose a "used initialized" in a dead branch in the
>>>        findidx function.  */
>>>     UCHAR str;
>> And it gets even more interesting if you dig into the history of this code.
>>
>> https://sourceware.org/ml/libc-alpha/2014-11/msg00459.html
>>
>> The implication is this is dead code in the case we're looking at.
>>
>> I wonder if the solution here is to disable the oob warning along with
>> the uninit warning.
> 
> A key follow-up from Joseph (easy to get lost in the thread...)
> 
> https://sourceware.org/ml/libc-alpha/2014-11/msg00616.html
> https://sourceware.org/ml/libc-alpha/2014-11/msg00635.html
> 
> Leading to...
> 
> https://sourceware.org/ml/libc-alpha/2014-11/msg00639.html
> 
> Jeff
> 
Hi,

I am seeing the same failure in our aarch64 builds, though when I first
saw this I thought it was something similar to BZ23396.

Carlos hints at that in
https://sourceware.org/ml/libc-alpha/2018-07/msg00388.html

If you look at how nhere is initialized in findidx in locale/weightwc.h:
      /* Next is the length of the byte sequence.  These are always
         short byte sequences so there is no reason to call any
         function (even if they are inlined).  */
      nhere = *cp++;

As far as I can tell, when we call this using a single char array, the
next element will not be the length of the byte sequence.

Exiting early when 'nhere >= len' makes the warning go away. I am not at
all familiar with this code though so I might be swinging at windmills here.

Cheers,
Andre