From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x334.google.com (mail-ot1-x334.google.com [IPv6:2607:f8b0:4864:20::334]) by sourceware.org (Postfix) with ESMTPS id 3C2863857C50 for ; Fri, 9 Jul 2021 19:46:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3C2863857C50 Received: by mail-ot1-x334.google.com with SMTP id w15-20020a056830144fb02904af2a0d96f3so10622081otp.6 for ; Fri, 09 Jul 2021 12:46:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Zm9pcCylHtIPYrWRyPLMaU2GSRLJPwxn2tebDX+TXfY=; b=D8WRyRvntRqYGyDVQgF+ShDZdjrdDjZDx4qtgCWd9Wrq5UA2tIZfqdEqYhUK24jKg8 yAV8lPxaYup0YBjhqxN0i/IMJ4aFoAKLZ6EQUyZG2CKTB7CxYoge3MISFLHJUx5TaVGx EQ4YHiQeLFONEdiGBy80x/JegCdsy57d7TcR6nj1QWTRW2ewn7Rnv7GjhhxK1hXq2iFb IRpUWdK8X7ZFtTQAikYVj2UruPEDXXBQE7ffZRZ1f9Cw3MpeSf95u8AHpksInxIstOJ1 pCAviG9wRcm8XQDfzu1/gr+B721SXcr3XPxN9H96E2chtJabumEQA0GITgJiMjd18imY FplQ== X-Gm-Message-State: AOAM531sNuFZIWFC2W38/VF4wwxkLP/TPOtpXXaJS3HCa1IwsoRfXQqr k3UZbWb83pVbKILzBCiTV2s= X-Google-Smtp-Source: ABdhPJyhQTKffI5oXGzCN+w6T/Oi0C9YI0RMC0CKdlDlFwjhNFcjtyatVrV0cnNfSXJxk2NJyPcCrQ== X-Received: by 2002:a9d:450d:: with SMTP id w13mr3155819ote.372.1625859986671; Fri, 09 Jul 2021 12:46:26 -0700 (PDT) Received: from [192.168.0.41] (75-166-102-22.hlrn.qwest.net. [75.166.102.22]) by smtp.gmail.com with ESMTPSA id t10sm1178484oor.48.2021.07.09.12.46.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Jul 2021 12:46:26 -0700 (PDT) Subject: Re: disable -Warray-bounds in libgo (PR 101374) To: Maxim Kuvyrkov Cc: Richard Biener , gcc-patches , Ian Lance Taylor , Richard Henderson References: <9F56A005-47B2-4593-BCB4-B8FAD3533955@linaro.org> From: Martin Sebor Message-ID: Date: Fri, 9 Jul 2021 13:46:25 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <9F56A005-47B2-4593-BCB4-B8FAD3533955@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2021 19:46:28 -0000 On 7/9/21 7:19 AM, Maxim Kuvyrkov wrote: >> On 9 Jul 2021, at 09:16, Richard Biener via Gcc-patches wrote: >> >> On Thu, Jul 8, 2021 at 8:02 PM Martin Sebor via Gcc-patches >> 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