[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&D 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 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&action=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 --- Comment #14 from Rogério de Souza Moraes --- Created attachment 49747 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49747&action=edit File which all the 'try' macros are taken out to separate routines, for build performance improvement
[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 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 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&action=edit C code to trigger the uninitialized warning The C code attached reproduces the uninitialized warning when compiled with -O3.
[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 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 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&action=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 * &)&local_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 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&action=edit C++ code to reproduce the issue. C++ code 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 #3 from Rogério de Souza Moraes --- Created attachment 53288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53288&action=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 #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 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 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/include/c++/13.1.0/bits/new_allocator.h:147:55:
note: destination object of size 8 allocat
[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&action=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 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 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.h:506:3 , inlined fr
[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&action=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++/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&action=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<_IsMove, true, std::
[Bug tree-optimization/110498] Spurious warnings stringop-overflow and array-bounds copying data as bytes into vector::reserve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110498 Rogério de Souza Moraes changed: What|Removed |Added Version|13.1.0 |12.4.0 --- Comment #4 from Rogério de Souza Moraes --- This issue now is affecting the GCC 12.4.0 as you can see at https://godbolt.org/z/8xr6eMeha.
[Bug tree-optimization/115824] [12 Regression] Strange -Warray-bounds warning when assigning an initializer list to a vector of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115824 --- Comment #4 from Rogério de Souza Moraes --- I confirm that GCC 12.4.0 with r12-10250-g8ec265c1464dec reverted fixes the issue reported here.
[Bug c++/117925] New: ice unexpected expression '(FnPtr)(fnPtr)' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117925
Bug ID: 117925
Summary: ice unexpected expression '(FnPtr)(fnPtr)' of kind
cast_expr
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
GCC 14 returns a compiler internal error for the code below
(https://godbolt.org/z/b8EenvKj8):
using FnPtr = int(*)();
template
void fnICE(void* fnPtr)
{
((FnPtr)fnPtr)();
}
The error message is:
: In function 'void fnICE(void*)':
:6:6: internal compiler error: unexpected expression '(FnPtr)(fnPtr)'
of kind cast_expr
6 | ((FnPtr)fnPtr)();
| ~^
0x2031cbc internal_error(char const*, ...)
???:0
0x7f6550 cp_get_fndecl_from_callee(tree_node*, bool)
???:0
0x7f6be1 convert_to_void(tree_node*, impl_conv_void, int)
???:0
0x95bca1 finish_expr_stmt(tree_node*)
???:0
0x90ee14 c_parse_file()
???:0
0xa0d1b9 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/117925] [14/15 Regression] ice unexpected expression '(FnPtr)(fnPtr)' of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117925 --- Comment #2 from Rogério de Souza Moraes --- Another workaround raised by the team I work with is to use reinterpret_cast: (*(FnPtr)fnPtr)() Reinterpret_cast doesn't cause the ICE as well.
[Bug tree-optimization/107919] Possibly false-positive "maybe-uninitialized" with GCC 12 on complex variant-variant-tuple-unique_ptr types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919 --- Comment #13 from Rogério de Souza Moraes --- I have backported the patches, but it seems that they are not enough to fix this issue on 12.4. If you want I could attach them to this bugzilla.
[Bug tree-optimization/107919] Possibly false-positive "maybe-uninitialized" with GCC 12 on complex variant-variant-tuple-unique_ptr types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919 Rogério de Souza Moraes changed: What|Removed |Added CC||rogerio.souza at gmail dot com --- Comment #10 from Rogério de Souza Moraes --- This still affects GCC 14.2.0. Are there any plans to fix it for 12.5.0? On GCC 13.3.0 the issue does not happen.
[Bug tree-optimization/107919] Possibly false-positive "maybe-uninitialized" with GCC 12 on complex variant-variant-tuple-unique_ptr types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107919 --- Comment #11 from Rogério de Souza Moraes --- This still affects GCC 12.4.0. Are there any plans to fix it for 12.5.0? On GCC 13.3.0 the issue does not happen.
[Bug tree-optimization/111073] [13/14/15 regression] False-positive -Wstringop-overflow when building gdb from trunk with -D_GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111073
Rogério de Souza Moraes changed:
What|Removed |Added
CC||rogerio.souza at gmail dot com
--- Comment #6 from Rogério de Souza Moraes ---
We got similar issue with a very small code using GCC v14.2:
https://godbolt.org/z/b5dqvnKqj
**
#include
void foo(int mod_id, std::vector> &_modMpcCluster) {
std::vector cluster;
cluster.push_back(mod_id);
_modMpcCluster.push_back(cluster);
}
**
g++ -c -fpic -std=c++26 -O -DNDEBUG -Wall -Werror xxx.cpp
This returns the error:
```
In file included from
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.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 =
const int; _Up = int; bool _IsMove = false]',
inlined from 'constexpr _OI std::__copy_move_a2(_II, _II, _OI) [with bool
_IsMove = false; _II = const int*; _OI = int*]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:521:30,
inlined from 'constexpr _OI std::__copy_move_a1(_II, _II, _OI) [with bool
_IsMove = false; _II = const int*; _OI = int*]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:548:42,
inlined from 'constexpr _OI std::__copy_move_a(_II, _II, _OI) [with bool
_IsMove = false; _II = __gnu_cxx::__normal_iterator >;
_OI = int*]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:555:31,
inlined from 'constexpr _OI std::copy(_II, _II, _OI) [with _II =
__gnu_cxx::__normal_iterator >; _OI = int*]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:651:7,
inlined from 'static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = __gnu_cxx::__normal_iterator >; _ForwardIterator = int*]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_uninitialized.h:147:27,
inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator =
__gnu_cxx::__normal_iterator >; _ForwardIterator =
int*]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_uninitialized.h:185:15,
inlined from 'constexpr _ForwardIterator
std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator,
allocator<_Tp>&) [with _InputIterator = __gnu_cxx::__normal_iterator >; _ForwardIterator = int*; _Tp = int]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_uninitialized.h:373:37,
inlined from 'constexpr std::vector<_Tp, _Alloc>::vector(const
std::vector<_Tp, _Alloc>&) [with _Tp = int; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_vector.h:606:31,
inlined from 'constexpr decltype (::new(void*(0)) _Tp)
std::construct_at(_Tp*, _Args&& ...) [with _Tp = vector; _Args = {const
vector >&}]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_construct.h:97:14,
inlined from 'static constexpr void
std::allocator_traits >::construct(allocator_type&, _Up*,
_Args&& ...) [with _Up = std::vector; _Args = {const std::vector >&}; _Tp = std::vector]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/alloc_traits.h:536:21,
inlined from 'constexpr void std::vector<_Tp, _Alloc>::push_back(const
value_type&) [with _Tp = std::vector; _Alloc =
std::allocator >]' at
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_vector.h:1288:30,
inlined from 'void foo(int, std::vector >&)' at
:6:30:
/opt/compiler-explorer/gcc-14.2.0/include/c++/14.2.0/bits/stl_algobase.h:452:30:
error: 'void* __builtin_memmove(void*, const void*, long unsigned int)' forming
offset 4 is out of the bounds [0, 4] [-Werror=array-bounds=]
452 | __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
| ~^~~
cc1plus: all warnings being treated as errors
```
[Bug tree-optimization/119417] New: -fexpensive-optimizations forces GCC 14 to use uxtw instead of uxth causing different result on ADD instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119417
Bug ID: 119417
Summary: -fexpensive-optimizations forces GCC 14 to use uxtw
instead of uxth causing different result on ADD
instruction
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
Greetings,
GCC 14 running on aarch64 architecture, our team detected a unique behavior
that only happens when we use the optimization “-fexpensive-optimizations”.
We noted that the line “buggy = buggy + ((global & 0x) * 2);” from the code
below has different instructions if using the “-fexpensive-optimizations” or
not.
# With -fexpensive-optimizations uses uxtw
add x19, x19, w0, uxtw 1
# Without -fexpensive-optimizations uses uxth
add x19, x19, w0, uxth 1
The reduced testcase is available at https://godbolt.org/z/vM9Y4dMnW.
To reproduce use the command "gcc -O1 -fexpensive-optimizations":
#include
__attribute__((noinline)) void print(size_t toPrint)
{
std::cout << toPrint << std::endl;
}
unsigned global = 0x1;
int main()
{
size_t buggy = 0;
while (true)
{
buggy = buggy + ((global & 0x) * 2);
print(buggy);
if (global)
break;
}
}
This source code returns 0 when NOT using “-fexpensive-optimizations” and
returns 131072 when using this flag or -O2 or higher optimization.
We tested it with older GCC versions and also LLVM, only GCC 14 on Arm returns
131072.
Knowning that UXTH extends a 16-bit unsigned value to a 32-bit register and
UXTW
extends a 32-bit unsigned value to a 64-bit register, forcing a uint16_t cast
fixes this behavior as the example below:
buggy = buggy + (static_cast(global & 0x) * 2);
print(buggy);
This GCC 14 behavior is a bug or it is expected and the other versions and LLVM
should be fixed?
Regards,
Rogerio
[Bug tree-optimization/119417] [14/15 Regression] wrong code with `-O2`, uses uxtw instead of uxth causing different result on ADD instruction since r14-8680-g2f14c0dbb78985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119417 --- Comment #6 from Rogério de Souza Moraes --- I confirm that the patch gcc15-pr119417.patch backported to GCC 14.2 fixed the issue on Arm (aarch64). Is this patch going to be used on trunk and officially backported to GCC 14.2?
[Bug c++/119334] New: error: loop variable '' creates a copy from type 'const std::pair' [-Werror=range-loop-construct]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119334
Bug ID: 119334
Summary: error: loop variable '' creates a
copy from type 'const std::pair'
[-Werror=range-loop-construct]
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rogerio.souza at gmail dot com
Target Milestone: ---
The code below returns the warning ":10:21: warning: loop variable
'' creates a copy from type 'const std::pair'
[-Wrange-loop-construct]" from GCC 11.0 to 14.2. Using GCC from trunk the
warning is not raised. I used all levels of optimization and all have failed.
The command line to reproduce is "g++ -fpic -std=c++17 -pthread -O3 -Wall
-DNDEBUG".
Below is the source code "https://godbolt.org/z/5TeaqoEen":
***
#include
#include
void bar(int x, int y);
std::vector> v;
void foo()
{
for (const auto [x, y] : v)
bar(x, y);
for (const auto p : v)
bar(p.first, p.second);
}
***
Regards,
Rogerio
