[Bug c++/114379] New: stringop-overflow warning on C++ code with -O2 (or -O1 -fexpensive-optimizations)

[Bug c++/114379] New: stringop-overflow warning on C++ code with -O2 (or -O1 -fexpensive-optimizations)

[denilsonsa at gmail dot com]

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

            Bug ID: 114379
           Summary: stringop-overflow warning on C++ code with -O2 (or -O1
                    -fexpensive-optimizations)
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: denilsonsa at gmail dot com
  Target Milestone: ---

Created attachment 57724
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57724&action=edit
The preprocessed C++ file (foo.ii), generated from the c++ source-code in the
description.

There are almost 100 open bug reports related to stringop-overflow. It's very
likely this bug report over here is a duplicate to one of those. In fact, many
of those are likely duplicates as well. Someone needs to trial them and close
the duplicates.
https://gcc.gnu.org/bugzilla/buglist.cgi?quicksearch=stringop-overflow

Meanwhile, over here… Let me describe the bug.

This bug was originally found when trying to compile
obs-advanced-scene-switcher version 1.25.3 on Manjaro Linux. It fails
compilation.

* https://github.com/WarmUpTill/SceneSwitcher
* https://aur.archlinux.org/packages/obs-advanced-scene-switcher#comment-961879

I also found other projects that also faced this bug and decided to just
disable that warning.

* https://github.com/ClickHouse/ClickHouse/issues/10508
* https://github.com/oneapi-src/oneTBB/issues/843
*
https://github.com/falcosecurity/libs/pull/952/commits/0b689250555e27dd71554a27dfa0346ddb6a26e1

Then I did some investigation and wrote down a minimal testcase. It's a very
trimmed-down version of the source-code of obs-advanced-scene-switcher. It's
enough to trigger the compiler warning/error depending on the compiler flags.

```
#include <atomic>
#include <deque>
#include <memory>
#include <string>

class ActionQueue {
        public:
                void Stop() {
                        _stop = true;
                }
        protected:
                std::string _name = "";
        private:
                std::atomic_bool _stop = {false};
};

static std::deque<std::shared_ptr<ActionQueue>> queues;

int main(int argc, char *argv[])
{
        for (auto &queue : queues) {
                auto actionQueue =
                        std::dynamic_pointer_cast<ActionQueue>(queue);
                actionQueue->Stop();
        }
        return 0;
}
```

It compiles fine with:

    g++ -v foo.cpp -o foo -O1 -Wall -Werror=stringop-overflow

But it fails to compile with:

    g++ -v foo.cpp -o foo -O1 -Wall -Werror=stringop-overflow
-fexpensive-optimizations
    g++ -v foo.cpp -o foo -O2 -Wall -Werror=stringop-overflow

With this error:

```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=ada,c,c++,d,fortran,go,lto,m2,objc,obj-c++
--enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/ --with-build-config=bootstrap-lto
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-libstdcxx-backtrace
--enable-link-serialization=1 --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.1 20230801 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'foo' '-O1' '-Wall'
'-Werror=stringop-overflow' '-fexpensive-optimizations' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/cc1plus -E -quiet -v -D_GNU_SOURCE
foo.cpp -mtune=generic -march=x86-64 -Wall -Werror=stringop-overflow
-fexpensive-optimizations -O1 -fpch-preprocess -o foo.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1

/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/x86_64-pc-linux-gnu

/usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/../../../../include/c++/13.2.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'foo' '-O1' '-Wall'
'-Werror=stringop-overflow' '-fexpensive-optimizations' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/13.2.1/cc1plus -fpreprocessed foo.ii -quiet
-dumpbase foo.cpp -dumpbase-ext .cpp -mtune=generic -march=x86-64 -O1 -Wall
-Werror=stringop-overflow -version -fexpensive-optimizations -o foo.s
GNU C++17 (GCC) version 13.2.1 20230801 (x86_64-pc-linux-gnu)
        compiled by GNU C version 13.2.1 20230801, GMP version 6.3.0, MPFR
version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f089b864c6bcbc2427e9850aa6414a11
In file included from /usr/include/c++/13.2.1/atomic:41,
                 from foo.cpp:1:
In member function ‘void std::__atomic_base<_IntTp>::store(__int_type,
std::memory_order) [with _ITp = bool]’,
    inlined from ‘std::__atomic_base<_IntTp>::__int_type
std::__atomic_base<_IntTp>::operator=(__int_type) [with _ITp = bool]’ at
/usr/include/c++/13.2.1/bits/atomic_base.h:373:7,
    inlined from ‘bool std::atomic<bool>::operator=(bool)’ at
/usr/include/c++/13.2.1/atomic:80:31,
    inlined from ‘void ActionQueue::Stop()’ at foo.cpp:9:10,
    inlined from ‘int main(int, char**)’ at foo.cpp:24:20:
/usr/include/c++/13.2.1/bits/atomic_base.h:481:25: error: ‘void
__atomic_store_1(volatile void*, unsigned char, int)’ writing 1 byte into a
region of size 0 overflows the destination [-Werror=stringop-overflow=]
  481 |         __atomic_store_n(&_M_i, __i, int(__m));
      |         ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
In function ‘int main(int, char**)’:
cc1plus: note: destination object is likely at address zero
cc1plus: some warnings being treated as errors
```

The system is x86_64 Manjaro Linux. I have not tested other versions of GCC.
Given the amount of related bug reports, I'm gonna assume this bug has been
around for a while.

[Bug c++/114379] stringop-overflow warning on C++ code with -O2 (or -O1 -fexpensive-optimizations)

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Blocks|                            |88443

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The diagnostic hints at jump threading producing an access to nullptr.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug c++/114379] stringop-overflow warning on C++ code with -O2 (or -O1 -fexpensive-optimizations)

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-03-18
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> The diagnostic hints at jump threading producing an access to nullptr.

Yes, I saw this happening with std::atomic recently too - I can't remember if I
still have the code to reproduce it.