[Bug c++/114178] New: incorrect -Wstringop-overflow with freestanding + placement new w/ initialization + no sse

[Bug c++/114178] New: incorrect -Wstringop-overflow with freestanding + placement new w/ initialization + no sse

[evan.teran at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178

            Bug ID: 114178
           Summary: incorrect -Wstringop-overflow with freestanding +
                    placement new w/ initialization + no sse
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: evan.teran at gmail dot com
  Target Milestone: ---

Created attachment 57580
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57580&action=edit
dockerized example of the issue for both gcc 12 and gcc 13

This seems to be circumstantial, so I'll try to explain with as much detail as
I can. I have a personal OS project which I use c++ to develop for. Starting
with gcc-12 and gcc-13 I started getting an warnings triggered by
`-Wstringop-overflow`, which is a bit frustrating since I prefer to compile
with `-Werror`.

After spending some time narrowing it down, it boils down to this code
triggering the warning:

```
template <class T>
void dont_optimize_away(T &&value) {
        asm volatile("" : "+r"(value));
}

int foo() {
        auto contents = new char[128]();

        dont_optimize_away(contents);

        delete[] contents;
        return 0;
}

```

As you can see, there really isn't much code here get wrong!

Compiling this file with the following flags results in the warning:

```
-std=c++17           # benign
-O3                  # required for issue
-march=x86-64        # benign
-ffreestanding       # required for issue
-Wstringop-overflow  # the warning in question
-mno-red-zone        # benign (somewhat required for osdev)

-mno-avx             # OS dev typically disables things like SSE and similar
-mno-avx2 
-mno-mmx 
-mno-sse 
-mno-sse2 
-mno-sse3 
-mno-sse4 
-mno-sse4.1 
-mno-sse4.2 
-mno-sse4a 
-mno-ssse3 
```

Here's where it gets confusing/interesting:

1. if I change `auto contents = new char[128]();` to `auto contents = new
char[128];` then i don't get the warning. Presumably, the issue is triggered by
the initialization of the array being created.

2. if I remove `-ffreestanding`, the warning goes away

3. if I remove `-mno-mmx`, the warning goes away

4. if I remove BOTH `-mno-sse` and `-mno-sse2`, the warning goes away

5. different combinations of the `-mno-xxxx` flags result in slight differences
to the warnings.

It seems to me, that with this setup, the compiler is emitting something
comparable to a memset to initialize the array and is highly unrolling it.
Something about this code with these flags is triggering the warning.

I don't know if the emitted code is legitimately reaching outside the bounds of
the buffer, or if warning is just getting confused.

I will be attaching a dockerized example of the issue which can be run by
simply  untarring and running `./build.sh`

Thanks

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed. There is a dup of this bug somewhere. Basically the vectorizer is
causing some IR which shows up the warning. Yes even though you disable the
vector instruction sets, the vectorizer still happens, specifically with the
idea that `vector(8) char` stores could be done using the 64bit GPRs

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-02-29
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=111154

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Specifically PR 111154  but there might be others.

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

[evan.teran at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178

--- Comment #4 from Evan Teran <evan.teran at gmail dot com> ---
@Andrew, thanks for the quick analysis! Just to confirm, the warning is in fact
incorrect and the emitted code is not stomping outside of the buffer bounds?

I ask because I did also one last bit, which is that changing the buffer size
can make the warning go away. That is if I make the buffer in the example
something like 132, then it's happy again, which at the very least, makes me
wonder if the vectorized code is in fact going out of bounds when the size
doesn't align with the vectorized code's expectations.

[Bug tree-optimization/114178] incorrect -Wstringop-overflow with freestanding + new w/ initialization + no sse

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114178

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Evan Teran from comment #4)
> @Andrew, thanks for the quick analysis! Just to confirm, the warning is in
> fact incorrect and the emitted code is not stomping outside of the buffer
> bounds?
> 
> I ask because I did also one last bit, which is that changing the buffer
> size can make the warning go away. That is if I make the buffer in the
> example something like 132, then it's happy again, which at the very least,
> makes me wonder if the vectorized code is in fact going out of bounds when
> the size doesn't align with the vectorized code's expectations.

The code is not incorrect, It is the peel part for unaligned part of the
stores. Just the warning is not using the same information that the peeling
part had available to it and getting confused by it.

Basically -ffreestanding is needed to hit the warning because GCC will use
memset rather than vectorize the store loop. Adding
-fno-tree-loop-distribute-patterns instead of -ffreestanding will also cause
the warning for the same reason.