This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Re: ToT build error with ToT GCC on Aarch64
- From: "Andre Vieira (lists)" <Andre dot SimoesDiasVieira at arm dot com>
- To: libc-alpha at sourceware dot org
- Cc: carlos at redhat dot com
- Date: Tue, 24 Jul 2018 10:06:45 +0100
- Subject: Re: Re: ToT build error with ToT GCC on Aarch64
- References: <1532361092.15609.7.camel@cavium.com> <e3582c68-63e3-92f6-824c-5e9ec38f6b8d at redhat dot com> <b1d3ff3c-72e6-fd4f-ded4-27208fc6194d at redhat dot com> <93fee3af-210e-5aeb-f514-0fd1117e3087 at gmail dot com> <e92b9819-5d59-1aed-8139-19c74174aba9 at gmail dot com> <2d58ee1f-1461-9ac4-11c9-daf4970768d5 at redhat dot com> <3a5397be-2e59-a6c2-2101-ac10e2524492@redhat.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