public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Amol <suratiamol@gmail.com>, gcc-help <gcc-help@gcc.gnu.org>
Subject: Re: False warnings on arm-gcc?
Date: Fri, 29 Jul 2022 16:54:17 -0600	[thread overview]
Message-ID: <b3ed4218-bed8-d646-bb96-df49c46150aa@gmail.com> (raw)
In-Reply-To: <CA+nuEB8O1qUt2gWrGwSVk-TvEvCxNwFr8kufaUWiD+vVBqRATQ@mail.gmail.com>

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


      reply	other threads:[~2022-07-29 22:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-29  8:56 Amol
2022-07-29 22:54 ` Martin Sebor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b3ed4218-bed8-d646-bb96-df49c46150aa@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    --cc=suratiamol@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).