On 11/6/19 4:09 PM, Maciej W. Rozycki wrote:
> On Fri, 1 Nov 2019, Martin Sebor wrote:
> 
>> Rebuilding the kernel with the updated patch results in the following
>> breakdown of the two warnings (the numbers are total instances of each,
>> unique instances, and files they come from):
>>
>>    -Wzero-length-bounds                 49       46       13
>>    -Warray-bounds                       45       14        8
>>
>> The -Warray-bounds instances I checked look legitimate even though
>> the code is some of them still looks benign.  I'm not sure there's
>> a good way to relax the warning to sanction some of these abuses
>> without also missing some bugs.  It might be worth looking into
>> some more in stage 3, depending on the fallout during mass rebuild.
>>
>> After bootstrapping on x86_64 and i385 and regtesting I committed
>> the attached patch in r277728.
> 
>  It is what I believe has also broken glibc:
> 
> In file included from ../sysdeps/riscv/libc-tls.c:19:
> ../csu/libc-tls.c: In function '__libc_setup_tls':
> ../csu/libc-tls.c:209:30: error: array subscript 1 is outside the bounds of 
> an interior zero-length array 'struct dtv_slotinfo[0]' 
> [-Werror=zero-length-bounds]
>   209 |   static_slotinfo.si.slotinfo[1].map = main_map;
>       |   ~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
> In file included from ../sysdeps/riscv/ldsodefs.h:46,
>                  from ../sysdeps/gnu/ldsodefs.h:46,
>                  from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
>                  from ../sysdeps/unix/sysv/linux/riscv/ldsodefs.h:22,
>                  from ../csu/libc-tls.c:21,
>                  from ../sysdeps/riscv/libc-tls.c:19:
> ../sysdeps/generic/ldsodefs.h:423:7: note: while referencing 'slotinfo'
>   423 |     } slotinfo[0];
>       |       ^~~~~~~~
> cc1: all warnings being treated as errors
> 
> (here in a RISC-V build).
> 
>  Has anybody looked yet into how the breakage could possibly be addressed?
Yea, Florian posted patches over the weekend to fix glibc.  They're
still going through the review/update cycle.

jeff

Reply via email to