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.
