From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) by sourceware.org (Postfix) with ESMTPS id 5ADE538582A1 for ; Fri, 29 Jul 2022 22:54:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5ADE538582A1 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-f2a4c51c45so7433866fac.9 for ; Fri, 29 Jul 2022 15:54:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=sHRhEtD5p2DIeRqpB3r58OX6nS1OefrwesXaotl4QGU=; b=peZuvO8hnjQUaAhFkKacGTOjJTq4JJ7vlNgahMd2oxGxgZsx5LTDVMPzL5tJCFcdxZ wemza2G16FnTjBlDOA/2tOSPWHAoC/FIwAkm1XejiS85vPGzhgCOa/+07Ycc88ZQcYJY ltMWXjKu6nfW3yWUjL7nCKIbwOzg5mDQ8vv/PsL0txnAt+v42/o9Wgls5ML7mYtfAjo2 BuQw48ft4yPPa2/xT3l874apUfITkn49/B62W0xVtZyXbBRkChgHrTBcq3SMrk8DfS11 PTlfZQD1I4NsZnSLJk6mGPbH4frI8WGrAvbQQ9NurAOuWJ7gwIrjTUMq/DlIWGFspwjU FQjw== X-Gm-Message-State: AJIora9xKjF5NRB3S+xLYPDkV5bFg4Im7qJMfrZ8MkGWs0u1kmXj/4jC MZlclTWvQrSzxhKAEMJfcB4= X-Google-Smtp-Source: AGRyM1tUIvAZwY26ayFWJF6lV/hGedZoHCDHnKva7EP4AUOnx9BRD76HWZUQbPx5fs8BXDrxd5To4w== X-Received: by 2002:a05:6870:c588:b0:10c:4b3a:68ec with SMTP id ba8-20020a056870c58800b0010c4b3a68ecmr3060679oab.223.1659135258582; Fri, 29 Jul 2022 15:54:18 -0700 (PDT) Received: from [192.168.0.41] (184-96-229-227.hlrn.qwest.net. [184.96.229.227]) by smtp.gmail.com with ESMTPSA id h4-20020a056830164400b0061c9c7813d4sm1467943otr.24.2022.07.29.15.54.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Jul 2022 15:54:18 -0700 (PDT) Message-ID: Date: Fri, 29 Jul 2022 16:54:17 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: False warnings on arm-gcc? Content-Language: en-US To: Amol , gcc-help References: From: Martin Sebor In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2022 22:54:21 -0000 On 7/29/22 02:56, Amol via Gcc-help wrote: > Hello, > > The compilation of a program at [1] raises warnings which say that it > attempted to write beyond the buffer when it did not. > > Cmdline given to godbolt's arm-gcc-trunk(Linux) compiler: > -O3 -mno-unaligned-access -ffreestanding -mfloat-abi=soft > > Changing O3 to O2, or defaulting to hard float-abi, or removing > -mno-unaligned-access, or removing -ffreestanding - any one these > four steps result in a compilatoin with no warnings at all. With an arm-eabi cross-compiler on Linux (but not on Godbolt) I can trigger the same warning with just -O3 -ffreestanding and the small test case below. Without the latter option GCC just emits a call to __builtin_memset(this->all, 0, 32) which is fine. With -ffreestanding it vectorizes the stores in memsett into 4-byte stores and then the loop unroller unrolls the first four iterations of the loop but somehow doesn't end there and emits code to copy more data. It doesn't see that the loop copies exactly 16. struct S { unsigned long long a[4]; }; void f (struct S *p) { char *s = p->a; for (unsigned i = 0; i < sizeof p->a; ++i) s[i] = 0; } > > Is it because of any alignment or other issues that the program has > neglected? It looks like a problem with the loop unroller. There have been quite a few reports about it causing false positives, one just earlier this week: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106297 Since this case is so simple and different from all the others (that I've seen) and since the usual workaround of adding some annotation doesn't help GCC bound the number of iterations, it might be worth opening a new bug for it. Martin > > Thanks, > Amol > > [1] https://godbolt.org/z/rGvxP5qsr