Re: disable -Warray-bounds in libgo (PR 101374)

[Martin Sebor <msebor@gmail.com>]

On 7/9/21 7:19 AM, Maxim Kuvyrkov wrote:
>> On 9 Jul 2021, at 09:16, Richard Biener via Gcc-patches <gcc-patches@gcc.gnu.org> wrote:
>>
>> On Thu, Jul 8, 2021 at 8:02 PM Martin Sebor via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>>>
>>> Hi Ian,
>>>
>>> Yesterday's enhancement to -Warray-bounds has exposed a couple of
>>> issues in libgo where the code writes into an invalid constant
>>> address that the warning is designed to flag.
>>>
>>> On the assumption that those invalid addresses are deliberate,
>>> the attached patch suppresses these instances by using #pragma
>>> GCC diagnostic but I don't think I'm supposed to commit it (at
>>> least Git won't let me).  To avoid Go bootstrap failures please
>>> either apply the patch or otherwise suppress the warning (e.g.,
>>> by using a volatile pointer temporary).
>>
>> Btw, I don't think we should diagnose things like
>>
>>                 *(int*)0x21 = 0x21;
>>
>> when somebody literally writes that he'll be just annoyed by diagnostics.
> 
> And we have an assortment of similar cases in 32-bit ARM kernel-page helpers.
> 
> At the moment building libatomic for arm-linux-gnueabihf fails with:
> ===
> In function ‘select_test_and_set_8’,
>      inlined from ‘select_test_and_set_8’ at /home/tcwg-buildslave/workspace/tcwg-dev-build/snapshots/gcc.git~master/libatomic/tas_n.c:115:1:
> /home/tcwg-buildslave/workspace/tcwg-dev-build/snapshots/gcc.git~master/libatomic/config/linux/arm/host-config.h:42:34: error: array subscript 0 is outside array bounds of ‘unsigned int[0]’ [-Werror=array-bounds]
>     42 | #define __kernel_helper_version (*(unsigned int *)0xffff0ffc)
>        |                                 ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ===
> 
> In libatomic/config/linux/arm/host-config.h we have:
> ===
> /* Kernel helper for 32-bit compare-and-exchange.  */
> typedef int (__kernel_cmpxchg_t) (UWORD oldval, UWORD newval, UWORD *ptr);
> #define __kernel_cmpxchg (*(__kernel_cmpxchg_t *) 0xffff0fc0)
> 
> /* Kernel helper for 64-bit compare-and-exchange.  */
> typedef int (__kernel_cmpxchg64_t) (const U_8 * oldval, const U_8 * newval,
> 				    U_8 *ptr);
> #define __kernel_cmpxchg64 (*(__kernel_cmpxchg64_t *) 0xffff0f60)
> 
> /* Kernel helper for memory barrier.  */
> typedef void (__kernel_dmb_t) (void);
> #define __kernel_dmb (*(__kernel_dmb_t *) 0xffff0fa0)
> 
> /* Kernel helper page version number.  */
> #define __kernel_helper_version (*(unsigned int *)0xffff0ffc)
> ===

This failure is tracked in pr101379.  I have added an untested POC
patch with a possible way to avoid the warning.  Other approaches
are possible (I mention some in my comment on the bug) but they
are limited by the exposure of the constant address using macros.
Hiding them behind APIs instead would make it possible to suppress
the warnings via #pragma GCC diagnostic.  Alternatively, making
the addresses extern const variables would hide the constants from
the warning altogether.

With a suitable attribute an API or variable could also describe
the size of the object.  The AVR back end, for example, has two
attributes for hardwired addresses: io and address.  One of them
(or another one like it) could be made the target-indendependent
way to declare global variables of any type at fixed addresses,
e.g., like so:

   extern __attribute__ ((address (0xffff0fc0))) __kernel_cmpxchg64_t
   __kernel_cmpxchg;

Martin