[Bug c++/111496] New: Optimizer issue when reinitializing an object of a standard-layout class with a trivial copy constructor and a trivial destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111496
Bug ID: 111496
Summary: Optimizer issue when reinitializing an object of a
standard-layout class with a trivial copy constructor
and a trivial destructor
Product: gcc
Version: 13.2.1
URL: https://godbolt.org/z/hf8qf6qan
Status: UNCONFIRMED
Keywords: ABI, missed-optimization
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
Host: x86_64
Created attachment 55948
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55948=edit
Teste case to reproduce the optimization issue
In some cases, reinitializing an object of a standard-layout class with a
trivial copy constructor and a trivial destructor needs something more complex
than *this={} if this line is in a hot cycle. For some reason, gcc creates an
new object on stack which is copied to the target location.
Well, it's literally what *this={} should do, but I expected the compiler to
elide the copying.
Calling the destructor explicitly and reconstructing the object with a
placement new gives the desired code without the extra copying, but looks kinda
ugly.
The issue seems to be present in gcc9, gcc12, and gcc13, but different contents
the class trigger the generation of inferior code. Clang seems to produce the
shortest and the fastest code for this kind of operation.
Using -Os makes the compiler generate the improved binary code. Also replacing
"[[gnu::used]] void reset() { *this = {}; }" per "[[gnu::used]] void reset() {
A2 a2; *this = a2; }" improved the binary code generated.
The reproducible example is available at:
https://godbolt.org/z/hf8qf6qan
Source code:
#include
struct A {
[[gnu::used]] void reset() { *this = A(); }
private:
int b[4] = {};
char* p = {};
int x = {};
};
struct A2 {
[[gnu::used]] void reset() { *this = {}; }
private:
int b[4] = {};
char* p = {};
int x = {};
};
struct A3 {
[[gnu::used]] void reset() {
this->~A3();
new(this) A3;
}
private:
int b[4] = {};
char* p = {};
int x = {};
};
-
Regards,
Rogerio
[Bug middle-end/111118] New: Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18
Bug ID: 18
Summary: Bogus -Wstringop-overread with -std=gnu++20 -O2 and
std::vector
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Keywords: alias, diagnostic, missed-optimization, patch
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
The following C++ code compiled with "-c -O1 -std=gnu++20
-Werror=stringop-overread" emits a bogus warning/error with gcc trunk, while it
works without problem when using "-O1 -std=gnu++17" or "-O0 -std=gnu++20"
instead. Tested on compiler explorer on x64 Linux
"https://godbolt.org/z/491jTvj65":
#include
struct S {
std::vector p;
void foo();
};
#ifdef INLINE
inline
#endif
void S::foo() {
p.reserve(64);
}
===
The code above works fine when running on GCC 12.3.0, but GCC starts raising
the warning bellow sicne GCC v13.1.
In file included from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/vector:62,
from :1:
In static member function 'static constexpr _Up* std::__copy_move<_IsMove,
true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp =
long unsigned int; _Up = long unsigned int; bool _IsMove = false]',
inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:506:30,
inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:533:42,
inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:540:31,
inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = long
unsigned int*; _OI = long unsigned int*]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:633:7,
inlined from 'constexpr std::vector::iterator
std::vector::_M_copy_aligned(const_iterator, const_iterator,
iterator) [with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_bvector.h:1303:28,
inlined from 'constexpr void std::vector::_M_reallocate(size_type) [with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/vector.tcc:851:40,
inlined from 'constexpr void std::vector::reserve(size_type)
[with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_bvector.h:1091:17,
inlined from 'void S::foo()' at :12:14:
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_algobase.h:437:30:
warning: 'void* __builtin_memmove(void*, const void*, long unsigned int)'
writing between 9 and 9223372036854775807 bytes into a region of size 8
overflows the destination [-Wstringop-overflow=]
437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
In file included from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/x86_64-linux-gnu/bits/c++allocator.h:33,
from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:46,
from
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/vector:63:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*) [with _Tp = long unsigned int]',
inlined from 'constexpr _Tp* std::allocator<
>::allocate(std::size_t) [with _Tp = long unsigned int]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/allocator.h:198:40,
inlined from 'static constexpr _Tp*
std::allocator_traits >::allocate(allocator_type&,
size_type) [with _Tp = long unsigned int]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/alloc_traits.h:482:28,
inlined from 'constexpr std::_Bvector_base<_Alloc>::_Bit_pointer
std::_Bvector_base<_Alloc>::_M_allocate(std::size_t) [with _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_bvector.h:643:48,
inlined from 'constexpr void std::vector::_M_reallocate(size_type) [with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/vector.tcc:849:43,
inlined from 'constexpr void std::vector::reserve(size_type)
[with _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-13.1.0/include/c++/13.1.0/bits/stl_bvector.h:1091:17,
inlined from 'void S::foo()' at :12:14:
/opt/compiler-explorer/gcc-13.1.0/inclu
[Bug other/110847] New: Inaccurate GCC documentation about -Wtsan and -Wxor-used-as-pow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110847 Bug ID: 110847 Summary: Inaccurate GCC documentation about -Wtsan and -Wxor-used-as-pow warnings Product: gcc Version: unknown URL: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.htm l Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: rogerio.souza at gmail dot com Target Milestone: --- On GCC online docs warnings page (https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html) there is the following explanation: "You can request many specific warnings with options beginning with ‘-W’, for example -Wimplicit to request warnings on implicit declarations. Each of these specific warning options also has a negative form beginning ‘-Wno-’ to turn off warnings; for example, -Wno-implicit. >>>This manual lists only one of the two forms, whichever is not the default<<<" However both -Wtsan and -Wxor-used-as-pow are listed as if they weren't on by default, but have the "This warning is enabled by default" text on their description. If the text above states that the documentation lists only one of the two forms, whichever is not the default, then it might be missleading. Regards, Rogerio
[Bug libstdc++/110498] New: Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498 Bug ID: 110498 Summary: Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve Product: gcc Version: 13.1.0 Status: UNCONFIRMED Keywords: diagnostic, missed-optimization Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rogerio.souza at gmail dot com Target Milestone: --- Created attachment 55432 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55432=edit This is the preprocessed file (*.i*) that triggers the warning reported here. The warning issue happens when using GCC v13.1.0 on Red Hat 7.9 3.10.0-1160.90.1.el7.x86_64. The compiler configuration settings are: /grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/gcc -v Using built-in specs. COLLECT_GCC=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/gcc COLLECT_LTO_WRAPPER=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/libexec/gcc/x86_64-redhat-linux/13.1.0/lto-wrapper Target: x86_64-redhat-linux Configured with: /tmp/gcc-v13.1.0d1rh74_lnx86/gcc.source/configure --prefix=/grid/common/test/gcc-v13.1.0d1rh74_lnx86 --with-pkgversion=Cadence --disable-libgcj --enable-threads=posix --enable-shared --with-system-zlib --enable-checking=release --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,fortran --disable-nls --enable-gnu-unique-object --enable-bootstrap --enable-plugin --enable-linker-build-id --enable-gnu-indirect-function --enable-install-libiberty --with-tune=generic --enable-initfini-array --enable-multiarch --with-linker-hash-style=gnu --with-ld=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/ld --with-as=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/as --build=x86_64-redhat-linux --host=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.1.0 (Cadence) = The command line to reproduce the warning and the compiler output: /opt/gcc-v13.1.0d1rh74_lnx86/bin/gcc -c -fpic -std=c++2b -pthread -D_GLIBCXX_USE_CXX11_ABI=1 -Wstrict-aliasing=3 -O3 -Wall -Werror -DNDEBUG -Wstrict-aliasing=3 -Wextra -DET7 -DETX=7 -DCMG_QT_VERSION='"MAIN_WXE_23.05.539.d000-Z2, VEngineering"' -DLINUX2 -I/opt/ua/3party/capnproto -I/opt/ua/Framework -I. -I.. -I/opt/ap/include -I/grid/cva/p4/eugene/gcc_wxe/ua/include -I/opt/ua/3party/xlm_inst/include -MMD ../radbSerializer.C In file included from /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/string:51, from /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/stdexcept:39, from ../radbSerializer.C:9: In static member function 'static constexpr _Up* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = long unsigned int; _Up = long unsigned int; bool _IsMove = false]', inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:506:3 , inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:533:4 , inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:540:31, inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:633:7, inlined from 'constexpr std::vector::iterator std::vector::_M_copy_aligned(const_iterator, const_iterator, iterator) [with _Alloc = std::allocator]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_bvector.h:1303:28, inlined from 'constexpr void std::vector::_M_reallocate(size_type) [with _Alloc = std::allocator]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/vector.tcc:851:40, inlined from 'constexpr void std::vector::reserve(size_type) [with _Alloc = std::allocator]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_bvector.h:1091:17, inlined from 'radb::ScopesSerializer::ScopesSerializer()' at ../radbSerializer.C:25:24: /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:437:30: error: 'void* __builtin_memmove(void*, const void*, long unsigned int)' forming offset 8 is out of the bounds [0, 8] [-Werror=array-bounds=] 437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num); | ~^~~ In static member function 'static constexpr _Up* std::__copy_move
[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852 --- Comment #17 from Rogério de Souza Moraes --- Created attachment 55428 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55428=edit Preprocessed file for GCC 13.1.0 bug This is the preprocessed file (*.i*) that triggers the bug reported by Rogerio on GCC v13.1.0.
[Bug libstdc++/107852] [12 Regression] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107852 Rogério de Souza Moraes changed: What|Removed |Added CC||rogerio.souza at gmail dot com --- Comment #16 from Rogério de Souza Moraes --- I have a similar issue that happens using GCC v13.1.0 on Red Hat 7.9 3.10.0-1160.90.1.el7.x86_64. The compiler configuration settings are: /grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/gcc -v Using built-in specs. COLLECT_GCC=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/gcc COLLECT_LTO_WRAPPER=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/libexec/gcc/x86_64-redhat-linux/13.1.0/lto-wrapper Target: x86_64-redhat-linux Configured with: /tmp/gcc-v13.1.0d1rh74_lnx86/gcc.source/configure --prefix=/grid/common/test/gcc-v13.1.0d1rh74_lnx86 --with-pkgversion=Cadence --disable-libgcj --enable-threads=posix --enable-shared --with-system-zlib --enable-checking=release --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,fortran --disable-nls --enable-gnu-unique-object --enable-bootstrap --enable-plugin --enable-linker-build-id --enable-gnu-indirect-function --enable-install-libiberty --with-tune=generic --enable-initfini-array --enable-multiarch --with-linker-hash-style=gnu --with-ld=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/ld --with-as=/grid/common/test/gcc-v13.1.0d1rh74_lnx86/bin/as --build=x86_64-redhat-linux --host=x86_64-redhat-linux Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.1.0 (Cadence) = The command line to reproduce the crash and the compiler output: /opt/gcc-v13.1.0d1rh74_lnx86/bin/gcc -c -fpic -std=c++2b -pthread -D_GLIBCXX_USE_CXX11_ABI=1 -Wstrict-aliasing=3 -O3 -Wall -Werror -DNDEBUG -Wstrict-aliasing=3 -Wextra -DET7 -DETX=7 -DCMG_QT_VERSION='"MAIN_WXE_23.05.539.d000-Z2, VEngineering"' -DLINUX2 -I/opt/ua/3party/capnproto -I/opt/ua/Framework -I. -I.. -I/opt/ap/include -I/grid/cva/p4/eugene/gcc_wxe/ua/include -I/opt/ua/3party/xlm_inst/include -MMD ../radbSerializer.C In file included from /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/string:51, from /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/stdexcept:39, from ../radbSerializer.C:9: In static member function 'static constexpr _Up* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = long unsigned int; _Up = long unsigned int; bool _IsMove = false]', inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:506:3 , inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:533:4 , inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:540:31, inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:633:7, inlined from 'constexpr std::vector::iterator std::vector::_M_copy_aligned(const_iterator, const_iterator, iterator) [with _Alloc = std::allocator]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_bvector.h:1303:28, inlined from 'constexpr void std::vector::_M_reallocate(size_type) [with _Alloc = std::allocator]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/vector.tcc:851:40, inlined from 'constexpr void std::vector::reserve(size_type) [with _Alloc = std::allocator]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_bvector.h:1091:17, inlined from 'radb::ScopesSerializer::ScopesSerializer()' at ../radbSerializer.C:25:24: /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase.h:437:30: error: 'void* __builtin_memmove(void*, const void*, long unsigned int)' forming offset 8 is out of the bounds [0, 8] [-Werror=array-bounds=] 437 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num); | ~^~~ In static member function 'static constexpr _Up* std::__copy_move<_IsMove, true, std::random_access_iterator_tag>::__copy_m(_Tp*, _Tp*, _Up*) [with _Tp = long unsigned int; _Up = long unsigned int; bool _IsMove = false]', inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove = false; _II = long unsigned int*; _OI = long unsigned int*]' at /opt/gcc-v13.1.0d1rh74_lnx86/include/c++/13.1.0/bits/stl_algobase
[Bug tree-optimization/107004] [12 Regression] GCC12 warning in OOB access: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107004 --- Comment #5 from Rogério de Souza Moraes --- I tried to apply the patch r13-3596-ge7310e24b1c0ca67, but it has not fixed the issue. Although, the issue is not reproducible on GCC 13.1.0.
[Bug tree-optimization/107004] New: GCC12 warning in OOB access: array subscript is partly outside array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107004
Bug ID: 107004
Summary: GCC12 warning in OOB access: array subscript is partly
outside array bounds
Product: gcc
Version: 12.2.0
URL: https://godbolt.org/z/aoYh66EYb
Status: UNCONFIRMED
Keywords: TREE
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
The code below triggers the warning:
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/stl_construct.h:119:7:
warning: array subscript 'int*[0]' is partly outside array bounds of 'unsigned
char [8]' [-Warray-bounds]
119 | ::new((void*)__p) _Tp(std::forward<_Args>(__args)...);
| ^
Source code:
#include
#include
void foo(std::vector& v)
{
assert(v.size() >= 1);
v.resize(1);
}
Build command line:
g++ -std=c++20 -Wall -Wextra -pedantic -O3
Using -O2 prevents the warning, also if we use "-Wno-array-bounds". This issue
is not reproducible on GCC 11.3 or older.
Would this issue be a duplicate from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105348?
The issue could be reproduced on Compiler Explorer:
https://godbolt.org/z/aoYh66EYb
Regards,
Rogerio
[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238 --- Comment #4 from Rogério de Souza Moraes --- Hi Andrew, thank you for the quick reply. The "getLocalCopy" on this example is just to provide a quick way to reproduce the issue. Here is the getLocalCopy function of this example. extern void getLocalCopy(std::map&); I added the file bug2.cpp which is another way to reproduce the issue. The issue only happens when the compiler uses inline, which triggers the error on "stl_tree.h:2090:32". I could not find any condition that would consider the example codes as invalid or that leads to "undefined behavior", do you see any? Considering that this warning only happens on GCC 12.1, the testcases are valid wouldn´t it be an issue on this compiler version? Wouldn´t it require a fix on "stl_tree.h" to prevent this warning? Regards, Rogerio
[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238 --- Comment #3 from Rogério de Souza Moraes --- Created attachment 53288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53288=edit Second example to reproduce the issue
[Bug tree-optimization/106238] Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238 --- Comment #2 from Rogério de Souza Moraes --- Created attachment 53287 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53287=edit C++ code to reproduce the issue. C++ code to reproduce the issue.
[Bug libstdc++/106238] New: Inline optimization causes dangling pointer on "include/c++/12.1.0/bits/stl_tree.h"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106238
Bug ID: 106238
Summary: Inline optimization causes dangling pointer on
"include/c++/12.1.0/bits/stl_tree.h"
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
Created attachment 53282
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53282=edit
Preprocessed file to reroduce the issue
When compiling the code below, we get a dangling pointer warning.
#include
struct sysDLoc {/* Coordinates (in DBU) */
doublex, y;
};
std::map static_copy;
void realSwap()
{
std::map local_copy;
extern void getLocalCopy(std::map&);
getLocalCopy(local_copy);
local_copy.swap(static_copy);
}
Compilation command:
g++ -Wdangling-pointer -c -O2 bug.cpp
Warning log:
In file included from
/grid/common/test/gcc-v12.1.0d2rh74_lnx86/include/c++/12.1.0/map:60,
from bug.cpp:1:
In member function 'void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::swap(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>&) [with
_Key = int*; _Val = std::pair; _KeyOfValue =
std::_Select1st >; _Compare = std::less;
_Alloc = std::allocator >]',
inlined from 'void std::map<_Key, _Tp, _Compare,
_Alloc>::swap(std::map<_Key, _Tp, _Compare, _Alloc>&) [with _Key = int*; _Tp =
sysDLoc; _Compare = std::less; _Alloc = std::allocator >]' at
/grid/common/test/gcc-v12.1.0d2rh74_lnx86/include/c++/12.1.0/bits/stl_map.h:1172:18,
inlined from 'void realSwap()' at bug.cpp:14:18:
/grid/common/test/gcc-v12.1.0d2rh74_lnx86/include/c++/12.1.0/bits/stl_tree.h:2090:32:
warning: storing the address of local variable 'local_copy' in '*MEM[(struct
_Rb_tree_node_base * &)_copy + 16].std::_Rb_tree_node_base::_M_paren
' [-Wdangling-pointer=]
2090 | _M_root()->_M_parent = _M_end();
| ~^~
bug.cpp: In function 'void realSwap()':
bug.cpp:11:27: note: 'local_copy' declared here
11 | std::map local_copy;
| ^~
bug.cpp:11:27: note: 'local_copy.std::map,
std::allocator > >::_M_t.std::_Rb_tree, std::_Select1st
>, std::less, std::allocator >
>::_M_impl.std::_Rb_tree,
std::_Select1st >, std::less,
std::allocator >
>::_Rb_tree_impl,
true>::.std::_Rb_tree_header::_M_header.std::_Rb_tree_node_base::_M_parent'
declared here
This warning only happens on GCC v12.1. Using -O1,
"-fno-inline-small-functions”, or “-fno-inline-functions” prevents the error
from happening.
Regards,
Rogerio
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
--- Comment #6 from Rogério de Souza Moraes ---
I got another example with similar warning:
#
#include
//#pragma GCC diagnostic push
//#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#include
//#pragma GCC diagnostic pop
#include
namespace sysOs
{
std::regex rgxVer("ABC");
}
int main()
{
return 0;
}
###
The code above is available at https://godbolt.org/z/chsjPKE33.
Compiled with:
gcc -c -fPIC -Werror -std=c++2a -Wno-unused -O -Wall
it returns the warning:
/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:405:42:
error: '*(std::function*)((char*)&__tmp +
offsetof(std::__detail::_StateT,
std::__detail::_State::.std::__detail::_State_base::)).std::function::_M_invoker'
may be used uninitialized [-Werror=maybe-uninitialized]
405 | : _Function_base(), _M_invoker(__x._M_invoker)
| ^~
Would it be related with the same issue reported here? This example does not
raise the warning on GCC 11.3.
Regards,
--
Rogerio
[Bug target/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 --- Comment #3 from Rogério de Souza Moraes --- The code attached in the previous comment triggers the "warning: '__Y' is used uninitialized [-Wuninitialized]". The command line to compile it is: /grid/common/test/gcc-v12.1.0d1rh74_lnx86/bin/gcc -c -O3 -Wall ./a.C Using "-O1/-O2/-O3" the warning below is raised: In file included from /grid/common/test/gcc-v12.1.0d1rh74_lnx86/lib/gcc/x86_64-redhat-linux/12.1.0/include/immintrin.h:49, from ./a.C:1: In function '__m512i _mm512_permutexvar_epi64(__m512i, __m512i)', inlined from 'void UINT512_t::ithBit(int)' at ./a.C:12:40, inlined from 'WORD_t ithBitWORD(int) [with WORD_t = UINT512_t]' at ./a.C:27:13: /grid/common/test/gcc-v12.1.0d1rh74_lnx86/lib/gcc/x86_64-redhat-linux/12.1.0/include/avx512fintrin.h:6994:10: warning: '__Y' is used uninitialized [-Wuninitialized] 6994 | return (__m512i) __builtin_ia32_permvardi512_mask ((__v8di) __Y, | ^ 6995 | (__v8di) __X, | ~ 6996 | (__v8di) | 6997 | _mm512_undefined_epi32 (), | ~~ 6998 | (__mmask8) -1); | ~~ /grid/common/test/gcc-v12.1.0d1rh74_lnx86/lib/gcc/x86_64-redhat-linux/12.1.0/include/avx512fintrin.h: In function 'WORD_t ithBitWORD(int) [with WORD_t = UINT512_t]': /grid/common/test/gcc-v12.1.0d1rh74_lnx86/lib/gcc/x86_64-redhat-linux/12.1.0/include/avx512fintrin.h:206:11: note: '__Y' was declared here 206 | __m512i __Y = __Y; | ^~~ When compiling with -O0, the warning does not happen, so I believe it is due to the optimization that probably reduces the assembly code and triggers the warning. Is it correct? If so, what would be the best approach to suppress it? Would it be '#pragma GCC diagnostic ignored "-Wuninitialized"'?
[Bug target/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 --- Comment #2 from Rogério de Souza Moraes --- Created attachment 52971 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52971=edit C code to trigger the uninitialized warning The C code attached reproduces the uninitialized warning when compiled with -O3.
[Bug other/105593] New: avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593
Bug ID: 105593
Summary: avx512 math function raises uninitialized variable
warning
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
When using avx512 math function we got the following warning:
//lib/gcc/x86_64-redhat-linux/12.1.0/include/avx512fintrin.h:6994:10:
error: '__Y' may be used uninitialized [-Werror=maybe-uninitialized]
The code that triggers the error is the one below, from file avx512fintrin.h:
202 extern __inline __m512i
203 __attribute__ ((__gnu_inline__, __always_inline__, __artificial__))
204 _mm512_undefined_epi32 (void)
205 {
206 __m512i __Y = __Y; // Uninitialized variable "__Y"
207 return __Y;
208 }
Should this code be reviewed?
Using "-Wno-uninitialized" prevents this warning from happening.
[Bug tree-optimization/91257] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 --- Comment #14 from Rogério de Souza Moraes --- Created attachment 49747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49747=edit File which all the 'try' macros are taken out to separate routines, for build performance improvement
[Bug tree-optimization/91257] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 --- Comment #13 from Rogério de Souza Moraes --- Created attachment 49746 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49746=edit File that reproduces the current structure and has performance issues.
[Bug tree-optimization/91257] Compile-time and memory-hog hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91257 Rogério de Souza Moraes changed: What|Removed |Added CC||rogerio.souza at gmail dot com --- Comment #12 from Rogério de Souza Moraes --- Hi Richard, first, thank you for the great work improving the GCC performance. The R team which I am working with provided two test cases, they show that it was possible to reduce the build time by taking out the block containing setjmp/longjmp to a separate routine, which is only called from the original routine. Both attached files, example_base.c and example_routines.c, are generated in a very similar way, but in example_routines.c, all the 'try' macros are taken out to separate routines. The compilation times: example_base.c: v4.8.3 - 0m1.096s v6.3.0 - 0m16.017s v9.3.0 - 0m26.829s example_routines.c v4.8.3 - 0m0.955s v6.3.0 - 0m1.205s v9.3.0 - 0m1.617s Is this approach ok to improve the build performance? Even if this approach is OK, there are still details unclear to us, and some might be not even known: - Should we worry about inlining? Can we hint this to compiles, or should we make sure it's avoided (by using routine pointers, for example)? - Can we assume that routine call (with all low-level work like copying data on the stack etc.) is the only runtime performance price for this approach? - Is having many small routines instead of a few very large is universally good, or there are cases when it by itself can cause a problem? We appreciate very much any feedback. Best regards, -- Rogerio
[Bug middle-end/63155] [7 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #54 from Rogério de Souza Moraes --- Hi everyone, we continue to get performance degradation as we use a new compiler version to build the source code 'testcase-v1.c" that is available in the attachment above. Could you please check if the test case that I attached reproduces the same issue, or it is a different issue? Below are the results that I got: # GCC 4.4.7 -bash-4.1$ gcc -ftime-report -m32 -w -c -O3 -pedantic -fwrapv -mstackrealign -mpreferred-stack-boundary=4 testcase-v1.c -o testcase-v1.o Execution times (seconds) callgraph construction: 0.02 ( 0%) usr 0.01 ( 4%) sys 0.03 ( 0%) wall 2535 kB ( 1%) ggc callgraph optimization: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 11 kB ( 0%) ggc cfg cleanup : 0.05 ( 1%) usr 0.00 ( 0%) sys 0.07 ( 1%) wall 151 kB ( 0%) ggc trivially dead code : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc df reaching defs : 0.40 ( 4%) usr 0.01 ( 4%) sys 0.40 ( 4%) wall 0 kB ( 0%) ggc df live regs : 0.33 ( 3%) usr 0.00 ( 0%) sys 0.37 ( 4%) wall 0 kB ( 0%) ggc df live regs: 0.08 ( 1%) usr 0.00 ( 0%) sys 0.12 ( 1%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.17 ( 2%) usr 0.00 ( 0%) sys 0.16 ( 2%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 0.25 ( 3%) usr 0.00 ( 0%) sys 0.22 ( 2%) wall 2519 kB ( 1%) ggc register information : 0.13 ( 1%) usr 0.00 ( 0%) sys 0.11 ( 1%) wall 0 kB ( 0%) ggc alias analysis: 0.06 ( 1%) usr 0.00 ( 0%) sys 0.08 ( 1%) wall 1952 kB ( 1%) ggc register scan : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc rebuild jump labels : 0.06 ( 1%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.02 ( 0%) usr 0.02 ( 7%) sys 0.02 ( 0%) wall 466 kB ( 0%) ggc lexical analysis : 0.03 ( 0%) usr 0.02 ( 7%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc parser: 0.06 ( 1%) usr 0.07 (26%) sys 0.19 ( 2%) wall 18164 kB ( 9%) ggc inline heuristics : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 0.07 ( 1%) usr 0.00 ( 0%) sys 0.06 ( 1%) wall 19793 kB (10%) ggc tree CFG construction : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 4445 kB ( 2%) ggc tree CFG cleanup : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.06 ( 1%) wall 1209 kB ( 1%) ggc tree VRP : 0.20 ( 2%) usr 0.00 ( 0%) sys 0.20 ( 2%) wall 12984 kB ( 6%) ggc tree copy propagation : 0.10 ( 1%) usr 0.00 ( 0%) sys 0.05 ( 1%) wall 9 kB ( 0%) ggc tree find ref. vars : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1190 kB ( 1%) ggc tree PTA : 0.05 ( 1%) usr 0.00 ( 0%) sys 0.06 ( 1%) wall 33 kB ( 0%) ggc tree alias analysis : 0.04 ( 0%) usr 0.01 ( 4%) sys 0.03 ( 0%) wall 308 kB ( 0%) ggc tree flow sensitive alias: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree PHI insertion: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 1349 kB ( 1%) ggc tree SSA rewrite : 0.05 ( 1%) usr 0.00 ( 0%) sys 0.08 ( 1%) wall 16607 kB ( 8%) ggc tree SSA other: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA incremental : 0.11 ( 1%) usr 0.01 ( 4%) sys 0.06 ( 1%) wall 5142 kB ( 3%) ggc tree operand scan : 0.11 ( 1%) usr 0.03 (11%) sys 0.12 ( 1%) wall 10620 kB ( 5%) ggc dominator optimization: 0.08 ( 1%) usr 0.00 ( 0%) sys 0.11 ( 1%) wall 2130 kB ( 1%) ggc tree CCP : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 1%) wall 6 kB ( 0%) ggc tree split crit edges : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 6801 kB ( 3%) ggc tree reassociation: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 2 kB ( 0%) ggc tree PRE : 2.94 (31%) usr 0.02 ( 7%) sys 2.99 (30%) wall 4955 kB ( 2%) ggc tree FRE : 0.16 ( 2%) usr 0.01 ( 4%) sys 0.17 ( 2%) wall 1933 kB ( 1%) ggc tree code sinking : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1 kB ( 0%) ggc tree forward propagate: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree aggressive DCE : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc tree DSE : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 228 kB ( 0%) ggc PHI merge : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc complete unrolling: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 2 kB ( 0%) ggc tree SSA uncprop : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0
[Bug middle-end/63155] [7 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #53 from Rogério de Souza Moraes --- Created attachment 46627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46627=edit New testcase that shows performance degradation in GCC 9.1 This new testcase that shows performance degradation in GCC 9.1, the performance gets worst as we use a newer GCC version to build it. Example how to compile: gcc -ftime-report -m32 -w -c -O3 -pedantic -fwrapv -mstackrealign -mpreferred-stack-boundary=4 testcase-v1.c -o testcase-v1.o
[Bug middle-end/63155] [6/7/8 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #50 from Rogério de Souza Moraes --- Created attachment 44848 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44848=edit GCC 6.3.0 consolidated patch based on Richard's patches The patch attached is a backport based on Richard's patches to GCC v6.3.0. If any issues, please let me know. Regards, -- Rogerio
[Bug middle-end/63155] [6/7/8 Regression] memory hog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63155 --- Comment #35 from Rogério de Souza Moraes --- Created attachment 44791 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44791=edit Small testcase more similar to original environment Hi Richard, this is a new testcase, based on another file in the original environment. It’s quite small (7000 lines, 240 setjmp calls). This code with a little complex but still simplified control structure represents state machine implementation, which is very widely used by our customers. Another new factor is the nested setjmp calls. Of course, original testcase is more complex and takes even more time with more difference. You can run it using the following commands: time gcc -DGCC -DLINUX_C -D_GLIBCXX_USE_CXX11_ABI=0 -m32 -m32 -w -c -O0 -pedantic -fwrapv -mstackrealign -mpreferred-stack-boundary=4 gcc_2nd_synth_pure_c_item.c -o gcc_2nd_synth_pure_c_item.o time gcc -DGCC -DLINUX_C -D_GLIBCXX_USE_CXX11_ABI=0 -m32 -m32 -w -c -O -pedantic -fwrapv -mstackrealign -mpreferred-stack-boundary=4 gcc_2nd_synth_pure_c_item.c -o gcc_2nd_synth_pure_c_item.o Results : GCC: 4.8.5 (From RHEL 7.5) real0m0.349s user0m0.255s sys 0m0.083s real0m0.193s user0m0.163s sys 0m0.023s GCC: 6.3.0 (GCC 6.3.0 with Revision 264523 backported and applied to it) real0m32.235s user0m30.486s sys 0m1.622s real3m34.203s user3m33.726s sys 0m0.292s The performance difference is relevant in this test. Regards, -- Rogerio
[Bug libstdc++/82739] New: Sort is 30% slower compared to gcc44 on presorted array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82739
Bug ID: 82739
Summary: Sort is 30% slower compared to gcc44 on presorted
array
Product: gcc
Version: 7.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
In 2013 a bug was filed to fix a large performance degradation on
reverse-sorted array, which got fixed:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437
However there is near 60% performance degradation with GCC 7.2.0 compared to
GCC 4.4.5, this time when running std::sort on a forward-sorted array.
Here is the testcase:
sort.cpp
===
#include
#include
using namespace std;
int main()
{
const int num = 10;
std::vector v;
v.reserve(num);
for(int i=0;i!=num;++i) v.push_back(i);
sort(v.begin(), v.end());
// std::sort(std::begin(v), std::end(v));
}
===
Compilation Line: g++ -O3 sort.cpp -o sort
Run: time ./sort
# Server details
$ uname -a
Linux server 2.6.18-194.el5 #1 SMP Tue Mar 16 21:52:39 EDT 2010 x86_64 x86_64
x86_64 GNU/Linux
Results:
gcc version 4.1.2
real0m25.511s
user0m23.960s
sys 0m1.301s
gcc version 4.4.5
real0m20.241s
user0m18.716s
sys 0m1.328s
gcc version 4.8.3
real0m26.742s
user0m25.167s
sys 0m1.314s
gcc version 6.3.0
real0m33.911s
user0m32.312s
sys 0m1.266s
gcc version 7.2.0
real0m31.916s
user0m30.308s
sys 0m1.299s
Is there any way to improve the run-time performance?
