False warnings on arm-gcc?

False warnings on arm-gcc?

[Amol]

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.

Is it because of any alignment or other issues that the program has
neglected?

Thanks,
Amol

[1] https://godbolt.org/z/rGvxP5qsr

Re: False warnings on arm-gcc?

[Martin Sebor]

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