[Bug tree-optimization/107699] [12/13 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699 --- Comment #11 from Carlos Galvez --- Consider this more realistic example: https://godbolt.org/z/jbbqbe8d9 The compiler has all the information available to ensure that getCount().get() is smaller than 3, as enforced by the class invariant which is visible to the compiler. Class invariants help us not having to check things all the time. For example gsl::not_null allows us to not have to check for nullptr on every use.
[Bug c++/106901] New: False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
Bug ID: 106901
Summary: False positive -Warray-bounds with -O2 or higher?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi!
Here's some code snippet that I believe leads to a false positive for
Warray-bounds. It happens in trunk but not on GCC 12.2.
#include
bool bar(std::array const& vec,
std::size_t const size,
std::size_t const expected_size)
{
if (size < expected_size)
{
return false;
}
for (std::size_t i{expected_size}; i < size; ++i)
{
if (vec[i] != 0)
{
return false;
}
}
return true;
}
bool foo(std::array const& vec, std::size_t const size)
{
return bar(vec, size, 5);
}
In file included from :1:
In member function 'constexpr const std::array<_Tp, _Nm>::value_type&
std::array<_Tp, _Nm>::operator[](size_type) const [with _Tp = int; long
unsigned int _Nm = 5]',
inlined from 'bool bar(const std::array&, std::size_t,
std::size_t)' at :13:18,
inlined from 'bool foo(const std::array&, std::size_t)' at
:23:15:
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array:213:24:
warning: array subscript 5 is above array bounds of 'std::__array_traits::_Type' {aka 'const int [5]'} [-Warray-bounds]
213 | return _M_elems[__n];
|^
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array: In function
'bool foo(const std::array&, std::size_t)':
/opt/compiler-explorer/gcc-trunk-20220910/include/c++/13.0.0/array:109:55:
note: while referencing 'std::array::_M_elems'
109 | typename __array_traits<_Tp, _Nm>::_Type_M_elems;
| ^~~~
Example on Compiler Explorer:
https://godbolt.org/z/dKWdKrsTa
Since "size" is unknown to the compiler, it shouldn't be possible to tell with
certainty whether the loop is actually executed and therefore out-of-bounds
invoked.
Thanks!
[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 --- Comment #2 from Carlos Galvez --- If size == 5, expected_size == 5, then the loop is not executed, right?
[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 --- Comment #4 from Carlos Galvez --- Makes sense! Would it make sense to classify this as "maybe-array-bounds" instead? Similar to "maybe-uninitialized" vs "uninitialized"
[Bug c++/106901] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901
--- Comment #5 from Carlos Galvez ---
I also would like to understand why the warning is not triggered if the first
"if (size < expected_size)" is removed.
https://godbolt.org/z/7vqPxhsqo
The possibility of executing the loop and do out-of-bounds still exists, right?
So why is the compiler warning in one case and not other?
Similarly, a regular for-loop with "size" known at runtime is equally risky,
yet the compiler is not flagging it:
bool bar(std::array const& vec,
std::size_t const size)
{
for (std::size_t i{0}; i < size; ++i)
{
if (vec[i] != 0)
{
return false;
}
}
return true;
}
https://godbolt.org/z/6c64MEY7d
Personally, I think this warning should only warn about 100% confirmed OOB
cases, and put the "maybe" cases in a separate flag. All respectable projects
have as minimum "-Wall -Werror" in their compiler flags, to detect problems
that do exist, not that "might" exist. This can lead to quite a few false
positives, leading to people either disabling the warning altogether (which is
pretty bad!) or polluting the code with inline pragmas (disallowed by some
coding guidelines).
[Bug c++/106925] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106925
Bug ID: 106925
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
The following minimal example leads to a segfault of GCC on latest trunk:
#include
template
struct MyVector
{
std::array data{};
};
template
struct Foo final
{
T a{0};
};
constexpr std::size_t kSize = 1;
void foo(MyVector, kSize> input = MyVector, kSize>())
{
}
: In instantiation of 'constexpr MyVector, 1>::MyVector()':
:17:74: required from here
:6:25: internal compiler error: Segmentation fault
6 | std::array data{};
| ^~~~
0x23428ae internal_error(char const*, ...)
???:0
0xb9cae7 maybe_splice_retval_cleanup(tree_node*)
???:0
0xce4fc2 do_poplevel(tree_node*)
???:0
0xce7973 finish_for_stmt(tree_node*)
???:0
0xba5019 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int,
vec**)
???:0
0xd0ee2e expand_vec_init_expr(tree_node*, tree_node*, int, vec**)
???:0
0xd494d1 digest_nsdmi_init(tree_node*, tree_node*, int)
???:0
0xbaabe5 get_nsdmi(tree_node*, bool, int)
???:0
0xbd282d get_defaulted_eh_spec(tree_node*, int)
???:0
0xc9d42a maybe_instantiate_noexcept(tree_node*, int)
???:0
0xc9d23a maybe_instantiate_noexcept(tree_node*, int)
???:0
0xb85043 mark_used(tree_node*, int)
???:0
0xac7bfb build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xac9027 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xba3b2c build_value_init(tree_node*, int)
???:0
0xd4a73a build_functional_cast(unsigned int, tree_node*, tree_node*, int)
???:0
0xc743a7 c_parse_file()
???:0
0xdae9f9 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++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106925 --- Comment #2 from Carlos Galvez --- Hi, is there any progress on the issue?
[Bug c++/107200] New: False positive -Wdangling-pointer?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200
Bug ID: 107200
Summary: False positive -Wdangling-pointer?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi,
The following code triggers a -Wdangling-pointer on GCC 12 and GCC 13:
#include
#include
Eigen::Vector2d foo() {
return {1.0, 2.0};
}
int main()
{
auto x = 0.5 * foo();
std::cout << x(0) << ", " << x(1) << std::endl;
}
: In function 'int main()':
:10:23: note: unnamed temporary defined here
10 | auto x = 0.5 * foo();
|~~~^~
In member function 'const Eigen::internal::scalar_product_op::result_type Eigen::internal::scalar_product_op::operator()(const LhsScalar&, const RhsScalar&) const [with
LhsScalar = double; RhsScalar = double]',
inlined from
'Eigen::internal::binary_evaluator,
Eigen::internal::IndexBased, Eigen::internal::IndexBased>::CoeffReturnType
Eigen::internal::binary_evaluator,
Eigen::internal::IndexBased, Eigen::internal::IndexBased>::coeff(Eigen::Index)
const [with BinaryOp = Eigen::internal::scalar_product_op; Lhs
= const Eigen::CwiseNullaryOp,
const Eigen::Matrix >; Rhs = const Eigen::Matrix]'
at
/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/CoreEvaluators.h:719:21,
inlined from 'Eigen::DenseCoeffsBase::CoeffReturnType
Eigen::DenseCoeffsBase::coeff(Eigen::Index) const [with Derived =
Eigen::CwiseBinaryOp, const
Eigen::CwiseNullaryOp, const
Eigen::Matrix >, const Eigen::Matrix >]' at
/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/DenseCoeffsBase.h:144:59,
inlined from 'Eigen::DenseCoeffsBase::CoeffReturnType
Eigen::DenseCoeffsBase::operator()(Eigen::Index) const [with
Derived = Eigen::CwiseBinaryOp, const
Eigen::CwiseNullaryOp, const
Eigen::Matrix >, const Eigen::Matrix >]' at
/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/DenseCoeffsBase.h:181:19,
inlined from 'int main()' at :11:37:
/opt/compiler-explorer/libs/eigen/v3.3.9/Eigen/src/Core/functors/BinaryFunctors.h:86:128:
warning: using a dangling pointer to an unnamed temporary [-Wdangling-pointer=]
86 | EIGEN_DEVICE_FUNC EIGEN_STRONG_INLINE const result_type operator()
(const LhsScalar& a, const RhsScalar& b) const { return a * b; }
|
Reproducible on Godbolt: https://godbolt.org/z/7475f7WvK
The warning goes away with this change:
-auto x = 0.5 * foo();
+Eigen::Vector2d x = 0.5 * foo();
What could be the reason for this behavior?
Thanks!
[Bug tree-optimization/107200] False positive -Wdangling-pointer?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200 --- Comment #2 from Carlos Galvez --- Created attachment 53688 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53688&action=edit Preprocessed source Attaching preprocessed source. Had to use a tarball since it exceeds the 1 MB limit. Alternatively, you can get the same by adding "-E" to the flags in the Compiler Explorer example I posted above. Let me know if I can provide more info! Thanks for looking into it :)
[Bug tree-optimization/107200] False positive -Wdangling-pointer?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107200 Carlos Galvez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Carlos Galvez --- Wow, that's just mind blowing, thanks a lot! Can't believe we haven't caught this issue before...
[Bug tree-optimization/106901] [13 Regression] False positive -Warray-bounds with -O2 or higher?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106901 --- Comment #7 from Carlos Galvez --- I understand the reasoning, but the loop _can_ executed in other cases where the function is called with different arguments: bar(vec, 5, 5); // Warray-bounds, loop not executed, no runtime OOB. bar(vec, 5, 4); // No Warray-bounds, loop executed, no runtime OOB. There is no OOB access in either case, so the compiler is incorrect in claiming there is one. If there were, the OOB access would show up in Valgrind or ASan, which is not the case. Please note that the presence of False Positives in basic compiler warnings like Wall or Wextra damages the credibility of compiler warnings. Warnings that may have FPs should go in a different category, or as part of a separate tool, like a static analyzer.
[Bug c++/107252] New: False positive stringop-overflow, warning disappears if I remove unrelated code!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107252
Bug ID: 107252
Summary: False positive stringop-overflow, warning disappears
if I remove unrelated code!
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Created attachment 53702
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53702&action=edit
Preprocessed source
Hi,
I'm getting a false positive in the following reduced example (preprocessed
source attached):
#include
#include
class Test : public ::testing::Test
{
public:
std::vector x_{};
};
struct Bar
{
std::vector a;
std::vector b;
};
TEST_F(Test, Test1)
{
const std::vector x{1};
const std::vector y(2, 1);
std::vector z;
z.insert(z.end(), x.begin(),x.end());
Bar bar{};
bar.a = z;
}
TEST_F(Test, Test2)
{
const std::vector z{
1, 2, 3, 4, 5, 6,
7, 8, 9, 10, 11, 12,
13, 14, 15, 16, 17, 18,
19, 20, 21, 22, 23, 24,
25, 26
};
Bar bar{};
bar.a = x_;
}
In file included from
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/algorithm:60,
from
/opt/compiler-explorer/libs/googletest/trunk/googlemock/include/gmock/gmock-actions.h:137,
from
/opt/compiler-explorer/libs/googletest/trunk/googlemock/include/gmock/gmock.h:56,
from :1:
In static member function 'static _Tp* std::__copy_move<_IsMove, true,
std::random_access_iterator_tag>::__copy_m(const _Tp*, const _Tp*, _Tp*) [with
_Tp = unsigned char; bool _IsMove = true]',
inlined from '_OI std::__copy_move_a2(_II, _II, _OI) [with bool _IsMove =
true; _II = unsigned char*; _OI = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_algobase.h:497:30,
inlined from '_OI std::__copy_move_a1(_II, _II, _OI) [with bool _IsMove =
true; _II = unsigned char*; _OI = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_algobase.h:524:42,
inlined from '_OI std::__copy_move_a(_II, _II, _OI) [with bool _IsMove =
true; _II = unsigned char*; _OI = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_algobase.h:531:31,
inlined from '_OI std::copy(_II, _II, _OI) [with _II =
move_iterator; _OI = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_algobase.h:624:7,
inlined from 'static _ForwardIterator
std::__uninitialized_copy::__uninit_copy(_InputIterator, _InputIterator,
_ForwardIterator) [with _InputIterator = std::move_iterator;
_ForwardIterator = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_uninitialized.h:147:27,
inlined from '_ForwardIterator std::uninitialized_copy(_InputIterator,
_InputIterator, _ForwardIterator) [with _InputIterator = move_iterator; _ForwardIterator = unsigned char*]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_uninitialized.h:185:15,
inlined from '_ForwardIterator std::__uninitialized_copy_a(_InputIterator,
_InputIterator, _ForwardIterator, allocator<_Tp>&) [with _InputIterator =
move_iterator; _ForwardIterator = unsigned char*; _Tp =
unsigned char]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_uninitialized.h:373:37,
inlined from '_ForwardIterator
std::__uninitialized_move_if_noexcept_a(_InputIterator, _InputIterator,
_ForwardIterator, _Allocator&) [with _InputIterator = unsigned char*;
_ForwardIterator = unsigned char*; _Allocator = allocator]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_uninitialized.h:399:2,
inlined from 'void std::vector<_Tp, _Alloc>::_M_range_insert(iterator,
_ForwardIterator, _ForwardIterator, std::forward_iterator_tag) [with
_ForwardIterator = __gnu_cxx::__normal_iterator >; _Tp = unsigned char; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/vector.tcc:801:9,
inlined from 'void std::vector<_Tp, _Alloc>::_M_insert_dispatch(iterator,
_InputIterator, _InputIterator, std::__false_type) [with _InputIterator =
__gnu_cxx::__normal_iterator
>; _Tp = unsigned char; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_vector.h:1779:19,
inlined from 'std::vector<_Tp, _Alloc>::iterator std::vector<_Tp,
_Alloc>::insert(const_iterator, _InputIterator, _InputIterator) [with
_InputIterator = __gnu_cxx::__normal_iterator >; = void; _Tp = unsigned
char; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bits/stl_vector.h:1481:22,
inlined from 'virtual void Test_Test1_Test::TestBody()' at :23:13:
/opt/compiler-explorer/gcc-trunk-20221013/include/c++/13.0.0/bi
[Bug tree-optimization/107252] False positive stringop-overflow, warning disappears if I remove unrelated code!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107252 --- Comment #2 from Carlos Galvez --- To clarify, even removing things from the second function has an impact on the first function (which is where the warning comes from). Shouldn't both functions be independent?
[Bug c++/106925] [12/13 Regression] ICE in maybe_splice_retval_cleanup at gcc/cp/except.cc:1330 since r12-8066-g4822108e61ab8790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106925 --- Comment #8 from Carlos Galvez --- Awesome, thanks a lot for the quick fix!
[Bug c++/107290] New: False positive -Wuninitialized with Eigen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107290
Bug ID: 107290
Summary: False positive -Wuninitialized with Eigen
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Created attachment 53713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53713&action=edit
Preprocessed source
Hi,
I'm getting a false positive in the following code (preprocessed attached):
#include
using Points = Eigen::Array;
struct Foo
{
explicit Foo(Points p);
Points p_{};
};
void foo()
{
Points p{};
Foo Foo(p);
}
Compiling with flags:
-std=c++14 -Wall -Wextra -O3
In file included from /opt/compiler-explorer/libs/eigen/v3.3.7/Eigen/Core:450,
from :1:
In copy constructor 'Eigen::DenseStorage::DenseStorage(const Eigen::DenseStorage&) [with T = float; int Size = 3; int _Rows = 3; int _Cols = 1; int
_Options = 0]',
inlined from 'Eigen::PlainObjectBase::PlainObjectBase(const
Eigen::PlainObjectBase&) [with Derived = Eigen::Array]'
at
/opt/compiler-explorer/libs/eigen/v3.3.7/Eigen/src/Core/PlainObjectBase.h:520:17,
inlined from 'Eigen::Array<_Scalar, _Rows, _Cols, _Options, _MaxRows,
_MaxCols>::Array(const Eigen::Array<_Scalar, _Rows, _Cols, _Options, _MaxRows,
_MaxCols>&) [with _Scalar = float; int _Rows = 3; int _Cols = 1; int _Options =
0; int _MaxRows = 3; int _MaxCols = 1]' at
/opt/compiler-explorer/libs/eigen/v3.3.7/Eigen/src/Core/Array.h:229:25,
inlined from 'void foo()' at :14:14:
/opt/compiler-explorer/libs/eigen/v3.3.7/Eigen/src/Core/DenseStorage.h:194:47:
warning: 'p.Eigen::Array::.Eigen::PlainObjectBase
>::m_storage.Eigen::DenseStorage::m_data' is used
uninitialized [-Wuninitialized]
194 | DenseStorage(const DenseStorage& other) : m_data(other.m_data) {
| ^~~~
: In function 'void foo()':
:13:12: note: 'p' declared here
13 | Points p{};
|^
Repro on Godbolt: https://godbolt.org/z/TaTdT33vr
Interestingly, if I define the constructor inline, then the warning disappears:
- explicit Foo(Points p);
+ explicit Foo(Points p) : p_(std::move(p)) {}
[Bug c++/107361] New: Why does -Wclass-memaccess require trivial types, instead of trivially-copyable types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107361
Bug ID: 107361
Summary: Why does -Wclass-memaccess require trivial types,
instead of trivially-copyable types?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
I find -Wclass-memaccess warns on this kind of code:
#include
struct Foo
{
int x{};
char y{};
int z{};
};
int main()
{
Foo a;
std::memset(&a, 0, sizeof(a));
}
All because Foo has default member initializers, making it a non-trivial type.
It's still trivially-copyable, which is the requirement for std::memset.
Therefore I ask: why is the warning stricter than it needs to be?
Making sure structs are initialized is defensive programming, and consistent
with coding guidelines that require classes to initialize their data members.
Also, there are cases where we cannot use the C++ initialization (Foo a = {};).
For example, this class has implicit padding, and the C++ initialization will
not initialize that. This is a problem for serializer/deserializer type of code
(copying/reading uninitialized padding bytes, valgrind will complain).
[Bug c++/103862] New: Regression: -Wold-style-cast warns about system macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862
Bug ID: 103862
Summary: Regression: -Wold-style-cast warns about system macros
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi,
I thought this problem was solved by reading this:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12258
But I can still find it on GCC 11.1:
// include/third_party.h
#pragma once
#define MY_CAST(x) ((int)x)
// main.cpp
#include
int main()
{
int x = MY_CAST(123);
return x;
}
# g++-11 -isystem include -Wold-style-cast main.cpp
In file included from main.cpp:1:
main.cpp: In function 'int main()':
main.cpp:5:21: warning: use of old-style cast to 'int' [-Wold-style-cast]
5 | int x = MY_CAST(123);
| ^~~
# g++-11 --version
g++-11 (Ubuntu 11.1.0-1ubuntu1~20.04) 11.1.0
[Bug preprocessor/12258] -Wold-style-cast triggers on casts in macros from system headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12258 Carlos Galvez changed: What|Removed |Added CC||carlosgalvezp at gmail dot com --- Comment #6 from Carlos Galvez --- Hi, This problem seems to be back in GCC 9 and 11: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862
[Bug c++/103862] Regression: -Wold-style-cast warns about system macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862 --- Comment #1 from Carlos Galvez --- The problem exists also in GCC 9.4.0
[Bug c++/103862] Regression: -Wold-style-cast warns about system macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103862 --- Comment #3 from Carlos Galvez --- Interesting, thanks for the quick reply! In case it helps, if I include the header as a regular header, I do get the "note" referring to the system header: # g++-11 -I include -Wold-style-cast main.cpp In file included from main.cpp:1: main.cpp: In function 'int main()': main.cpp:5:21: warning: use of old-style cast to 'int' [-Wold-style-cast] 5 | int x = MY_CAST(123); | ^~~ include/third_party.h:3:26: note: in definition of macro 'MY_CAST' 3 | #define MY_CAST(x) ((int)x) |
[Bug driver/102803] New: Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 Bug ID: 102803 Summary: Bug: -no-canonical-prefixes not working Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: carlosgalvezp at gmail dot com Target Milestone: --- Hi, GCC has the option "-no-canonical-prefixes" to avoid calling "realpath" on default include search paths. This is needed when one wants to use GCC in Bazel: https://github.com/bazelbuild/bazel/issues/4605#issuecomment-364174051 Now, GCC as downloaded from here: http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu/pool/main/g/gcc-11/g++-11_11.1.0-1ubuntu1~18.04.1_amd64.deb does *not* honor the -no-canonical-prefixes flag. If one unpacks the above .deb file into e.g. /path/to/gcc, and runs gcc from there like ./usr/bin/gcc-11 with the -no-canonical-prefixes option, then the default search paths resolve all symlinks and "../", leading to a realpath: /path/to/gcc# ./usr/bin/gcc-11 -no-canonical-prefixes -fno-canonical-system-headers -xc++ -E -v - ignoring nonexistent directory "./usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/x86_64-linux-gnu/c++/11/x86_64-linux-gnu" ignoring nonexistent directory "./usr/bin/../lib/gcc/x86_64-linux-gnu/11/include" ignoring nonexistent directory "./usr/bin/../lib/gcc/x86_64-linux-gnu/11/include-fixed" ignoring nonexistent directory "./usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/path/to/gcc/usr/include/c++/11" ignoring duplicate directory "/path/to/gcc/usr/include/x86_64-linux-gnu/c++/11" ignoring duplicate directory "/path/to/gcc/usr/include/x86_64-linux-gnu/c++/11" ignoring duplicate directory "/path/to/gcc/usr/include/c++/11/backward" ignoring nonexistent directory "./usr/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring nonexistent directory "./usr/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11/include-fixed" ignoring nonexistent directory "./usr/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include" ignoring nonexistent directory "/usr/include/x86_64-linux-gnu" #include "..." search starts here: #include <...> search starts here: /path/to/gcc/usr/include/c++/11 /path/to/gcc/usr/include/x86_64-linux-gnu/c++/11 /path/to/gcc/usr/include/c++/11/backward /usr/local/include /usr/include I.e. the default search paths are: /path/to/gcc/usr/include/c++/11 /path/to/gcc/usr/include/x86_64-linux-gnu/c++/11 /path/to/gcc/usr/include/c++/11/backward Instead of: ./usr/bin/../include/c++/11 This happens also on GCC 7. Why is this happening? Can it be solved? This prevents GCC from being used in Bazel in a sandboxed way (i.e. without having GCC installed in the system).
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 --- Comment #2 from Carlos Galvez --- Did you read my detailed explanation and reproducible example? I took great care and time to make the problem easy to investigate. GCC is not doing what is supposed to do. Other compilers, like Clang, do actually apply the flag -no-canonical-prefixes. Putting the blame on Bazel doesn't sound like a good way to solve the problem.
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 --- Comment #4 from Carlos Galvez --- Thanks a lot for the detailed answer! That's very interesting, so it can actually have to do with how the Ubuntu version has been built. I'll definitely give it a try building locally. Your output looks like exactly what I would expect. The remaining /usr/include and /usr/local/include are due to the Linux system headers, which are GCC-agnostic (I think), so it makes sense that it picks them from there.
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 --- Comment #6 from Carlos Galvez --- Hmm I don't see that in the x86 version of Ubuntu GCC: Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Running your command prints nothing: /path/to/gcc# ./usr/bin/gcc-7 -print-sysroot /path/to/gcc# Same with: /path/to/gcc# ./usr/bin/gcc-7 -no-canonical-prefixes -print-sysroot /path/to/gcc#
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 Carlos Galvez changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #9 from Carlos Galvez --- Ok I've built from source with a different configuration than Ubuntu's and the -no-canonical-prefixes works as expected! So indeed it must be something in the Ubuntu configuration. I will then go and diff the configs to get to the root of this. Closing the bug as it's definitely not on GCC side, sorry for the confusion and thanks a lot for the help!
[Bug c++/107361] Why does -Wclass-memaccess require trivial types, instead of trivially-copyable types?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107361 --- Comment #2 from Carlos Galvez --- I understand the motivation and I think the warning makes a lot of sense! However I don't see how it could possibly be dangerous in the provided example. Would it suffice to trigger the warning only when a class has ctors/dtors/copy/move, which seems to be the intended use case?
[Bug c++/107677] New: -Warray-bounds: unclear what exactly it's meant to detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677 Bug ID: 107677 Summary: -Warray-bounds: unclear what exactly it's meant to detect Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: carlosgalvezp at gmail dot com Target Milestone: --- Hi, I have a hard time understanding -Warray-bounds. The documentation says: "It warns about subscripts to arrays that are always out of bounds" And yet, none of the hits of the warning are caught by sanitizer, nor by valgrind, nor by Clang. So how can it be that they "always" are out of bounds? Surely they should have been caught by some other tool, if it were so obvious? Some of the warnings go away if I "assert" that the subscript index is smaller than the size of the array, even if the assertion is not needed. Is GCC warning about "maybe" out of bounds cases, instead of "real" cases? Lastly, I find the stacktrace very confusing. It simply says "array subscript X is out of bounds". Where does this X come from? Is it real (and if so, where in the code is the number X defined?), or is it "a possibility" that may or may not happen based on runtime input? Thanks!
[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677 --- Comment #2 from Carlos Galvez --- This is a general question which I hope can be answered without a full report. My particular example gets a warning deep into Eigen-like code so it's not easy to provide a minimal example. My questions are code agnostic. Most importantly, I need to understand if this warning is expected to produce false positives in it's default setting with -Wall. The documentation says it catches subscripts that are "always" OOB. This is not the case, as confirmed with other tools. So, is the documentation accurate? Based on your experience with this warning, what type of code is it expected to warn on? It would be good to add this as part of the documentation. Finally, I ask if the subscript that GCC complains about is real or fictional (namely, it "could" be OOB but GCC can't know it statically). We've seen other warnings that complain about fictional numbers representing theoretical worst case, for example the max number of an int when unrolling a loop, which is possible in theory but unlikely in practice. Does this warning apply similar heuristics?
[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677 --- Comment #3 from Carlos Galvez --- The warning message is also hard to decipher. For example, what does this mean? error: array subscript [-536870912, -1] is outside array bounds What is a 2-dimensional subscript applied on a 1D array?
[Bug middle-end/107677] -Warray-bounds: unclear what exactly it's meant to detect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677 --- Comment #5 from Carlos Galvez --- Wow, that was mind blowing, thanks for the clarification! Such thing I'd like to have in the docs, it's very easy to confuse with the other message: note: at offset 48 into object '' of size 48 So one offset is an actual index, and the other is a "mathematical range of indices". Back to my example: error: array subscript [-536870912, -1] is outside array bounds I don't see these numbers in my code. Therefore I wonder: how does GCC compute these numbers? Are they based on my code, or are they based on: "if the user pass you the number -536870912 as input at runtime, then you'll do out-of-bounds"?
[Bug c++/107699] New: False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
Bug ID: 107699
Summary: False positive -Warray-bounds, non-existent offset
reported by GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi,
The following code:
#include
#include
std::size_t getCount();
int foo()
{
std::array data{3, 2, 1};
std::sort(data.begin(), data.begin() + getCount());
return data.front();
}
Built with -Wall -O3 triggers:
In file included from
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/algorithm:61,
from :2:
In function 'void std::__final_insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]',
inlined from 'void std::__final_insertion_sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:1854:5,
inlined from 'void std::__sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:1950:31,
inlined from 'void std::__sort(_RandomAccessIterator,
_RandomAccessIterator, _Compare) [with _RandomAccessIterator = int*; _Compare =
__gnu_cxx::__ops::_Iter_less_iter]' at
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:1942:5,
inlined from 'void std::sort(_RAIter, _RAIter) [with _RAIter = int*]' at
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:4860:18,
inlined from 'int foo()' at :9:14:
/opt/compiler-explorer/gcc-trunk-20221115/include/c++/13.0.0/bits/stl_algo.h:1859:32:
warning: array subscript 16 is outside array bounds of 'std::array [1]'
[-Warray-bounds]
1859 | std::__insertion_sort(__first, __first + int(_S_threshold),
__comp);
|
~^~
: In function 'int foo()':
:8:24: note: at offset 64 into object 'data' of size 12
8 | std::array data{3, 2, 1};
|^~~~
Compiler returned: 0
Repro: https://godbolt.org/z/Ma8KK1MKE
There is nowhere in the code any "offset 64". The compiler cannot possibly know
if there is OOB or not, since that depends on the function "getCount" which is
implemented in a separate translation unit.
Therefore the warning violates what the documentation says:
"It warns about subscripts to arrays that are always out of bounds"
This is not true in this case. It's not "always" out of bounds.
[Bug tree-optimization/107699] [12/13 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #2 from Carlos Galvez ---
Looking deeply at the stacktrace, I see that std::sort ends up in this kind of
code:
if (__last - __first > int(_S_threshold))
{
std::__insertion_sort(__first, __first + int(_S_threshold), __comp);
Since the __last iterator cannot be known at compile time, this "if" branch
must be generated by the compiler. But then std::sort has hardcoded this
_S_threshold = 16, and computes a pointer __first + 16, which is known to be
OOB.
The question is: should the compiler *really* warn in this type of code, in
-Wall, which is the bare-minimum warning level for all projects? While I can
see the usefulness, the sheer amount of false positives (see meta bug-tracker)
does not qualify this warning from being part of -Wall IMHO. This diagnostic
fits better as "-Wmaybe-array-bounds".
The worst part is that people need to disable this warning globally, therefore
losing warning coverage on *true* OOB accesses happening in user code.
[Bug tree-optimization/107699] [12/13 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699 --- Comment #5 from Carlos Galvez --- > is not good programming practice. Sure. In the real world, we have asserts for this. However this is a problem when we build for Release mode, in which asserts are disabled and thus this warning pops up.
[Bug tree-optimization/107699] [12/13 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699 --- Comment #6 from Carlos Galvez --- A similar case in the real world would be this: NumberSmallerThan3 getCount(); std::sort(data.begin(), data.begin() + static_cast(getCount())); The "NumberSmallerThan3" class holds and checks the invariant that "a number is smaller than 3". The compiler is not aware of that. Other real-world situation is Eigen-like code, where for performance reasons these checks can only be applied in debug mode, not release mode. We get warnings in release mode due to this.
[Bug tree-optimization/107699] [12/13 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699 --- Comment #8 from Carlos Galvez --- I see! In that case may I suggest to split the diagnostic into "Warray-bounds" and "Wmaybe-array-bounds"? That way we could enable the first and disable the second. The way it is today, we need to disable Warray-bounds entirely, which naturally risks not catching true positives.
[Bug c/12245] [10/11/12/13 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245
Carlos Galvez changed:
What|Removed |Added
CC||carlosgalvezp at gmail dot com
--- Comment #82 from Carlos Galvez ---
Hi,
This bug is still present in GCC 11.3.0. My use case is using large
std::arrays. NOTE: the problem immediately goes away if the arrays are not
initialized, but naturally we want to always initialize our variables to
prevent accessing uninitialized data:
-std::array data{};
+std::array data;
[Bug gcov-profile/111100] New: Use extern "C" for __gcov_dump and related functions in gcov.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=00 Bug ID: 00 Summary: Use extern "C" for __gcov_dump and related functions in gcov.h Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: carlosgalvezp at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Hi! The documentation of GCOV mentions that users can use __gcov_dump and __gcov_reset. This comes from gcov.h. The problem is that we currently can't use them in C++ code, because they don't have extern "C" declaration. Therefore the names are mangled which leads to linking errors (undefined reference) when using the code. As a workaround, people need to re-create gcov.h on their own to add the extern "C" declaration, or include the header under an extern "C" block, which is not very clean. Would it be possible to add extern "C" to the declarations in gcov.h? Thanks
[Bug c++/111714] New: Strange behavior when casting std::size_t to bool, UB or compiler bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 Bug ID: 111714 Summary: Strange behavior when casting std::size_t to bool, UB or compiler bug? Product: gcc Version: 9.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: carlosgalvezp at gmail dot com Target Milestone: --- Created attachment 56067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56067&action=edit Test case Hi! We are bumping from GCC 7.5 to 9.4 and one of our tests fail. The test works on GCC 10 and above, as well as Clang trunk. Sanitizers (GCC and Clang) and Valgrind don't report anything. I have managed to create a minimal example here: https://godbolt.org/z/3q7c4qYzE (attached to the bug as a file as well). There's also comments about changes to the code that can make the test pass. This smells a lot like UB, but I can't figure out what is wrong with the code. Otherwise it could well be a compiler bug. Is there anything obvious you can see that could explain the behavior? Thanks!
[Bug tree-optimization/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 --- Comment #3 from Carlos Galvez --- Thanks for the quick response! Unfortunately we are stuck on GCC 9 for reasons so I'll try to shuffle the code around a bit to make it work :)
[Bug c++/106294] GCC accepts the undefined behavior operation in a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106294 Carlos Galvez changed: What|Removed |Added CC||carlosgalvezp at gmail dot com --- Comment #2 from Carlos Galvez --- Please note: clang trunk now correctly detects this as a hard error. GCC might want to tag along: https://godbolt.org/z/54YvGPs6d
[Bug c++/95701] undefined enum conversion accepted in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95701 Carlos Galvez changed: What|Removed |Added CC||carlosgalvezp at gmail dot com --- Comment #3 from Carlos Galvez --- Clang trunk no longer accepts the code in the OP: https://godbolt.org/z/dK55xvTE4
[Bug c++/109642] New: False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642
Bug ID: 109642
Summary: False Positive -Wdangling-reference with
std::span-like classes
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi,
We are bumping our GCC installation from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
cc035c5d8672f87dc8c2756d9f8367903aa72d93 (GCC 13.1 release), and are now
getting a lot of False Positives from code that looks like this:
#include
#include
template
struct MySpan
{
MySpan(T* data, std::size_t size) :
data_(data),
size_(size)
{}
T& operator[](std::size_t idx) { return data_[idx]; }
private:
T* data_;
std::size_t size_;
};
template
MySpan make_my_span(T const(&x)[n])
{
return MySpan(std::begin(x), n);
}
template
std::span make_span(T const(&x)[n])
{
return std::span(std::begin(x), n);
}
int main()
{
int x[10]{};
int const& y{make_my_span(x)[0]};
int const& y2{make_span(x)[0]};
}
Godbolt: https://godbolt.org/z/Pf6jsezoP
I.e. when using std::span, GCC is happy, but when using our own implementation
of span (since we can't enable C++20 yet in our project due to reasons), then
it complains about dangling reference. Clang trunk does not warn about this.
It warns both about non-const and const references.
[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 --- Comment #2 from Carlos Galvez --- Is there a way to tag classes to mark them for exclusion? Currently the warning is part of -Wall and leads to many false positives. The warning message also says "possibly" dangling reference. In my opinion "possibly" type of warnings should not be part of -Wall due to the high FP rate. I also find it strange that it complains about const references, which anyway extend the lifetime of the temporary, or?
[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 --- Comment #4 from Carlos Galvez --- While I can do that on my own code, I cannot add that suppression on third-party code, like Eigen (which I also get a lot of false positives in similar code), even if I include the header via -isystem - since the warnings are on the client side. Is this really the expected behavior of a warning belonging to -Wall? Has this warning been tested on large projects to evaluate the false positive rate? Would you consider perhaps reducing the scope of the warning in order to reduce the false positive rate, alternatively move it out of Wall? It's sad that a lot of work and effort was put into creating this warning and it will just probably be disabled on most projects. When a tool produces a lot of false positives, there is high risk that developers stop trusting the tool and true positives are ignored.
[Bug c++/109663] New: False positive? Converting from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
Bug ID: 109663
Summary: False positive? Converting from initializer list would
use explicit constructor
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Created attachment 54950
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54950&action=edit
Preprocessed source
Hi!
We are bumping our GCC installation from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
cc035c5d8672f87dc8c2756d9f8367903aa72d93 (GCC 13.1 release), and are now
getting a handful of errors in this type of code compiling in C++14 mode:
#include
int main()
{
constexpr std::size_t kColumns{4};
constexpr std::size_t kRows{4};
using MyVector = Eigen::Matrix;
using MyMatrix = Eigen::Matrix;
MyMatrix matrix{MyMatrix::Zero()};
MyVector const& my_col{matrix.col(0)};
}
Godbolt: https://godbolt.org/z/rx6EY4qbY
Preprocessed source attached.
I am wondering if this is a False Positive or a real error that should be
fixed?
[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #1 from Carlos Galvez ---
I forgot to write the actual error I'm getting:
: In function 'int main()':
:11:41: error: converting to 'const MyVector' {aka 'const
Eigen::Matrix'} from initializer list would use explicit
constructor 'Eigen::Matrix<_Scalar, _Rows, _Cols, _Options, _MaxRows,
_MaxCols>::Matrix(const T&) [with T = Eigen::Block,
4, 1, true>; _Scalar = float; int _Rows = 4; int _Cols = 1; int _Options = 0;
int _MaxRows = 4; int _MaxCols = 1]'
11 | MyVector const& my_col{matrix.col(0)};
| ^
[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663
--- Comment #2 from Carlos Galvez ---
I could reduce it to a simpler self-contained example:
struct Foo;
Foo const& foo_maker();
struct Bar
{
explicit Bar(Foo const&);
};
void baz()
{
Bar const& b{foo_maker()};
}
Godbolt: https://godbolt.org/z/1q45Ebexz
Here it's clear that we are initializing a reference from a temporary, but
since it's a const reference, shouldn't it extend the lifetime of the
temporary? Clang does not complain in this case (it does when the reference is
non-const).
[Bug c++/109663] False positive? Converting from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663 Carlos Galvez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Carlos Galvez --- Thanks, I wasn't aware of that! Then it seems GCC is doing the right thing and I can close this bug, appreciate the quick responses!
[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109642 --- Comment #6 from Carlos Galvez --- Sounds great, thanks for the quick response! I believe "-Wall -Wextra" is the "bare minimum" set of warnings for most projects so I'm afraid people might still need to disable it via "-Wno*". Adding some [[gcc::whatever]] attribute sounds like a very interesting approach, I believe Clang has a similar thing. It's not really a blocker since we can just disable it, I'm just sad to have to do it since I believe it's a really good warning to have!
[Bug c++/109669] New: Internal Compiler Error when zero-initializing std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109669
Bug ID: 109669
Summary: Internal Compiler Error when zero-initializing
std::array
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi,
We are getting an ICE when bumping from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
cc035c5d8672f87dc8c2756d9f8367903aa72d93 (GCC 13.1.0 release) on the following
reduced example:
#include
template
struct Point
{
private:
T value_[n]{};
};
struct Edge
{
Point start{};
Point end{};
};
template
class StaticVector
{
public:
static StaticVector create()
{
StaticVector output;
return output;
}
private:
std::array data{};
};
class Polygon
{
public:
using Edges = StaticVector;
Edges edges() const
{
auto edges = Edges::create();
return edges;
}
};
void foo()
{
Polygon polygon{};
auto const edges = polygon.edges();
}
Godbolt: https://godbolt.org/z/183zv1xrK
Error:
: In instantiation of 'constexpr StaticVector::StaticVector()':
:22:22: required from 'static StaticVector StaticVector::create() [with T = Edge; long unsigned int n = 3]'
:36:35: required from here
:27:22: internal compiler error: Segmentation fault
27 | std::array data{};
| ^~~~
0x234da0e internal_error(char const*, ...)
???:0
0xccea48 finish_for_cond(tree_node*, tree_node*, bool, unsigned short)
???:0
0xb7bad3 build_vec_init(tree_node*, tree_node*, tree_node*, bool, int, int,
vec**)
???:0
0xce5cfb expand_vec_init_expr(tree_node*, tree_node*, int, vec**)
???:0
0xd200c1 digest_nsdmi_init(tree_node*, tree_node*, int)
???:0
0xb813b7 maybe_instantiate_nsdmi_init(tree_node*, int)
???:0
0xb819f9 get_nsdmi(tree_node*, bool, int)
???:0
0xba932d get_defaulted_eh_spec(tree_node*, int)
???:0
0xc76d4a maybe_instantiate_noexcept(tree_node*, int)
???:0
0xc76b5a maybe_instantiate_noexcept(tree_node*, int)
???:0
0xb5c2b3 mark_used(tree_node*, int)
???:0
0xa9931e build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0xa9a4c7 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
???:0
0xb7d468 build_aggr_init(tree_node*, tree_node*, int, int)
???:0
0xb4c768 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0xc80395 instantiate_decl(tree_node*, bool, bool)
???:0
0xcab7fb instantiate_pending_templates(int)
???:0
0xb5f735 c_parse_final_cleanups()
???:0
0xd8f918 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++/109663] False positive? Converting from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109663 --- Comment #8 from Carlos Galvez --- > Please don't close bugs as FIXED I did choose INVALID, was that not correct?
[Bug c++/109666] [13/14 Regression] Segmentation fault with std::array using gcc 13 since r13-6788
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109666 --- Comment #5 from Carlos Galvez --- This commit fixes all the ICEs on our side, thank you!
[Bug c++/109712] New: Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 Bug ID: 109712 Summary: Segmentation fault in linear_search_fdes Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: carlosgalvezp at gmail dot com Target Milestone: --- Created attachment 54978 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54978&action=edit Reproducible example Hi! We are bumping our GCC installation from 6910cad55ffc330dc9767d2c8e0b66ccfa4134af to 07c52d1eec9671af92b7ce977b469f13a87887ad and are now getting a segmentation fault when an exception is thrown, gdb points at "linear_search_fdes". Here's the backtrace: Thread 1 "a.out" received signal SIGSEGV, Segmentation fault. linear_search_fdes (ob=0x7fffd690, this_fde=0x0, pc=0x404248 ) at ../../../gcc/libgcc/unwind-dw2-fde.c:969 969 ../../../gcc/libgcc/unwind-dw2-fde.c: No such file or directory. (gdb) bt #0 linear_search_fdes (ob=0x7fffd690, this_fde=0x0, pc=0x404248 ) at ../../../gcc/libgcc/unwind-dw2-fde.c:969 #1 0x777c1e11 in find_fde_tail (dbase=18446744073709383432, bases=0x7fffd8e8, hdr=0x4aaa34, pc=4211272) at ../../../gcc/libgcc/unwind-dw2-fde-dip.c:519 #2 _Unwind_Find_FDE (pc=, bases=bases@entry=0x7fffd8e8) at ../../../gcc/libgcc/unwind-dw2-fde-dip.c:573 #3 0x777bd4aa in uw_frame_state_for (context=0x7fffd840, fs=0x7fffd930) at ../../../gcc/libgcc/unwind-dw2.c:1005 #4 0x777beefd in _Unwind_RaiseException (exc=0xcfc390) at ../../../gcc/libgcc/unwind.inc:104 #5 0x77bced8a in __cxa_throw () from /home/s069/src/src/bazel-src/external/gcc_trunk_x86_64_linux/usr/lib64/libstdc++.so.6 #6 0x00404249 in foo () at ../main.cpp:8 #7 0x004042a7 in main () at ../main.cpp:18 I attach a reproducible example that I have tested on Ubuntu 20.04, it will download dependencies and build the example project. It expects a "GCC_BASE" variable to be set pointing to the base GCC installation. I have made the following observations, so I'm not sure the problem is GCC, but I thought nevertheless to share it in case someone has a good intuition for what could be happening. If this is not the right forum please let me know where I should ask! * The problem happens only when linking libcudart_static.a. If I think libcudart.so it's fine. I have asked this question at the Nvidia forums as well, awaiting reply. * The problem happens only when throwing exceptions. * The problem happens only when using the Gold linker. * The problem happens only if I use the GCC trunk's libstdc++.so and libgcc_s.so at runtime (via rpath). If I use the Ubuntu 20.04 system-installed libraries, it runs fine. Thank you for your time!
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #4 from Carlos Galvez --- > Does libcudart_static.a by chance contain any symbols from the libgcc runtime I'm not sure, do you know how I could check that (I'm pretty n00b on these things :)). What I know is that libcudart.so does not have a dependency to neither libstdc++.so nor libgcc_s.so, only to libc, libdl, libpthread, librt. > This could also point to a bug with the GOLD linker. Indeed switching to BFD also solves the problem. I will try with LLD as well!
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 Carlos Galvez changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Carlos Galvez --- Works with LLD as well, so it seems likely a Gold bug. I wasn't aware is was no longer well maintained, good to know! Thanks again for your help :)
[Bug c++/109745] New: Incorrect code generated with -O1 when having a constexpr object modifying a mutable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745
Bug ID: 109745
Summary: Incorrect code generated with -O1 when having a
constexpr object modifying a mutable member
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi!
We are bumping our GCC installation from
6910cad55ffc330dc9767d2c8e0b66ccfa4134af to
07c52d1eec9671af92b7ce977b469f13a87887ad and one of our unit tests fails. I
have managed to reduce the code to the following minimal example, compiled with
-std=c++14 -O1:
#include
#include
template
class Foo {
public:
constexpr Foo() : has_value_{true} {}
Foo(Foo const& other) {
if (other.hasValue()) {
static_cast(new (&value_) T(other.value()));
has_value_ = true;
}
}
constexpr bool hasValue() const { return has_value_; }
constexpr T const& value() const { return value_; }
private:
T value_{};
bool has_value_{false};
};
enum class State {
initialized,
copy_constructed,
copied_from,
};
class Stateful {
public:
constexpr Stateful() = default;
constexpr Stateful(Stateful const& other)
: state_{State::copy_constructed} {
other.state_ = State::copied_from;
}
constexpr State state() const { return state_; }
private:
mutable State state_{State::initialized};
};
int main() {
constexpr Foo x{};
const Foo y{x};
assert(State::copied_from == x.value().state());
}
Godbolt: https://godbolt.org/z/oTd8M9P91
The problem seems to also appear between GCC 12.2 and 13.1.
The test runs fine on Clang trunk.
One observation is that if I make "x" 'const' instead of 'constexpr', the test
passes.
Do we have UB in our code, or is this an actual regression in GCC?
Thanks!
[Bug c++/109745] Incorrect code generated with -O1 when having a constexpr object modifying a mutable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745 --- Comment #1 from Carlos Galvez --- In case it wasn't clear: the test passes also on O0 - it only fails when increasing from O1 all the way to O3.
[Bug c++/109745] [13 Regression] Incorrect code generated with -O1 when having a constexpr object modifying a mutable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109745 --- Comment #8 from Carlos Galvez --- Thanks a lot for the quick fix!
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #6 from Carlos Galvez --- Hi again! I realized there is still one more problem missing, so I suspect the linker was not the only culprit. It does not segfault, but it gets stuck in an infinite loop, once again when mixing exceptions and libcudart_static.a. @Richard you mentioned: > Does libcudart_static.a by chance contain any symbols from the libgcc runtime > (of an old toolchain)? Do you know how I could verify this? I'm pretty new when it comes to troubleshooting these things. My understanding is that libstdc++.so and libgcc_s.so are always backwards compatible so using "the latest" ensures you can use the newest features and also run older built code. Is there a flaw/pitfall in that reasoning? Thanks!
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #8 from Carlos Galvez --- Upon closer inspection, it turns out we were building with GCC 7, but then using libgcc_s.so.1 and libstdc++.so.6 from GCC trunk at runtime (via LD_LIBRARY_PATH). Building with GCC trunk instead solves the segfault I described above. In particular it seems the problem is libgcc_s.so.1 - if I use the system-wide one (older) instead of the one from GCC trunk, the problem goes away. Is this expected though? My understanding was that libgcc_s and libstdc++ are backwards compatible, i.e. I can always keep the latest one installed on my system and I should be able to run applications linked against older libraries (which is what is happening here). There's also symbol versioning so old symbols are kept.
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #10 from Carlos Galvez --- Hi! I've continued to look into this and am having a slightly different but essentially same error with yet another Nvidia library, but this time is with a pure shared library, "libnvinfer.so", which was compiled against GCC 7. Most likely the library is statically linked against libcudart_static.a. The issue is not solved using bfd or lld linker. My program simply links against that library, which internally throws an exception. I get a very similar backtrace: #0 linear_search_fdes (ob=0x7fffd350, this_fde=0x0, pc=0x7fffdf4b6a69) at ../../../gcc/libgcc/unwind-dw2-fde.c:973 #1 0x7fffdde1cde1 in find_fde_tail (dbase=2424076, bases=0x7fffd5a8, hdr=0x7690ca70, pc=140736939649641) at ../../../gcc/libgcc/unwind-dw2-fde-dip.c:519 #2 _Unwind_Find_FDE (pc=, bases=bases@entry=0x7fffd5a8) at ../../../gcc/libgcc/unwind-dw2-fde-dip.c:573 #3 0x7fffdde1847a in uw_frame_state_for (context=0x7fffd500, fs=0x7fffd5f0) at ../../../gcc/libgcc/unwind-dw2.c:1005 #4 0x7fffdde19ecd in _Unwind_RaiseException (exc=0x904320) at ../../../gcc/libgcc/unwind.inc:104 #5 0x7fffde2b7e6a in __cxa_throw () from /path/to/usr/lib64/libstdc++.so.6 #6 0x7fffdf4b6a6a in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #7 0x7fffdf4c21b5 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #8 0x7fffdfbddf02 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #9 0x7fffdf42a118 in createInferBuilder_INTERNAL () from /path/to/nvinfer/lib/libnvinfer.so.8 #10 0x00401163 in nvinfer1::(anonymous namespace)::createInferBuilder (logger=...) at nvinfer/include/NvInfer.h:9093 #11 0x00401182 in main () at main.cpp:13 So the library was compiled with GCC 7 and has a dependency on libstdc++.so.6. Via LD_LIBRARY_PATH, I run my executable using GCC trunk (14)'s libstdc++.so.6. Now, I try to see if "libnvinfer_static.a" uses any symbol from "libgcc_eh.a", by doing: - Run "nm libgcc_eh.a" and store a list of all "T" or "t" symbols. - Run "nm libnvinfer_static.a" and store a list of all "U" symbols. - Compute the intersection between those two lists. This results in that "libnvinfer_static.a" only uses 1 symbol from libgcc_eh.a: _Unwind_Resume. Is the above test procedure correct to determine the symbols used from libgcc_eh.a? How come linking a pure shared library such as libnvinfer.so would lead to mixing types from different versions of libgcc_eh.a, i.e. how could those internal changes leak outside the shared library boundaries? After all this comes from __cxa_throw() from libstdc++.so.6, which is a versioned symbol. Shouldn't that function get a new symbol version if there's an ABI incompatible change? Thank you for your time and help, really appreciated!
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #12 from Carlos Galvez --- I just tested latest and greatest trunk (git commit 2415024e0f81f8c09bf08f947c790b43de9d0bbc) and the problem persists. Slightly different line numbers but essentially same backtrace: #0 linear_search_fdes (ob=0x7fffd1d0, this_fde=0x0, pc=0x7fffdf4b6624) at ../../../gcc/libgcc/unwind-dw2-fde.c:977 #1 0x7fffdde1ce51 in find_fde_tail (dbase=2424076, bases=0x7fffd428, hdr=0x7690ca70, pc=140736939648548) at ../../../gcc/libgcc/unwind-dw2-fde-dip.c:519 #2 _Unwind_Find_FDE (pc=, bases=bases@entry=0x7fffd428) at ../../../gcc/libgcc/unwind-dw2-fde-dip.c:573 #3 0x7fffdde184aa in uw_frame_state_for (context=0x7fffd380, fs=0x7fffd470) at ../../../gcc/libgcc/unwind-dw2.c:1005 #4 0x7fffdde19efd in _Unwind_RaiseException (exc=0x1d994fb0) at ../../../gcc/libgcc/unwind.inc:104 #5 0x7fffde2b808a in __cxa_throw () from /path/to/gcc/usr/lib64/libstdc++.so.6 #6 0x7fffdf4b6625 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #7 0x7fffdf0f5df3 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #8 0x7fffe1bff20b in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #9 0x7fffdf428c3f in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #10 0x7fffdf4297db in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #11 0x7fffdf429ef7 in ?? () from /path/to/nvinfer/lib/libnvinfer.so.8 #12 0x7fffdf42a17d in createInferBuilder_INTERNAL () from /path/to/nvinfer/lib/libnvinfer.so.8 #13 0x00401163 in nvinfer1::(anonymous namespace)::createInferBuilder (logger=...) at nvinfer/include/NvInfer.h:9093 #14 0x00401182 in main () at main.cpp:13
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #15 from Carlos Galvez --- Created attachment 55261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55261&action=edit Reproducible example nvinfer Attaching (hopefully) reproducible example as a tarball, containing: - download.sh: script to download an unpack the Nvidia dependencies. - test.sh: script to build and test the application. It expects a GCC_BASE environment variable existing pointing to the base GCC trunk installation/build. - a.out: the compiled binary. This has been tested on Ubuntu 22.04. Thank you for your time!
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #18 from Carlos Galvez --- Thanks for the investigation! To clarify: my last reproducible example does not use gold, instead it uses the default GNU ld version 2.38.
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #22 from Carlos Galvez --- Indeed it's an uninitialized read according to valgrind: ==15475== Use of uninitialised value of size 8 ==15475==at 0x1E81C2E9: base_from_object (unwind-dw2-fde.c:319) ==15475==by 0x1E81C2E9: linear_search_fdes (unwind-dw2-fde.c:975) ==15475==by 0x1E81CE50: find_fde_tail (unwind-dw2-fde-dip.c:519) ==15475==by 0x1E81CE50: _Unwind_Find_FDE (unwind-dw2-fde-dip.c:573) ==15475==by 0x1E8184A9: uw_frame_state_for (unwind-dw2.c:1005) ==15475==by 0x1E819EFC: _Unwind_RaiseException (unwind.inc:104) ==15475==by 0x1E2B8089: __cxa_throw (in /path/to/gcc/usr/lib64/libstdc++.so.6.0.32)
[Bug libgcc/109712] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712
--- Comment #25 from Carlos Galvez ---
Perhaps this is a stupid comment, but isn't "ob.s.b.encoding" uninitialized?
/* inside find_fde_tail */
struct object ob;
...
ob.pc_begin = NULL;
ob.tbase = NULL;
ob.dbase = (void *) dbase;
ob.u.single = (fde *) eh_frame;
ob.s.i = 0;
ob.s.b.mixed_encoding = 1; /* Need to assume worst case. */
const fde *entry = linear_search_fdes (&ob, (fde *) eh_frame, (void *) pc);
Above, only "ob.s.b.mixed_encoding" is set, not "ob.s.b.encoding".
After that, "linear_search_fdes" expects that it's set:
static const fde *
linear_search_fdes (struct object *ob, const fde *this_fde, void *pc)
{
const struct dwarf_cie *last_cie = 0;
int encoding = ob->s.b.encoding;
_Unwind_Ptr base = base_from_object (ob->s.b.encoding, ob);
[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #28 from Carlos Galvez --- The proposed patch fixes the issue on our side, thank you! I realize my comment about doesn't make sense - I was mixing unions in C (where type punning is fine) and C++ (UB). But then I don't understand why valgrind would point at that variable as uninitialized...
[Bug libgcc/109712] [13/14 Regression] Segmentation fault in linear_search_fdes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109712 --- Comment #29 from Carlos Galvez --- *my comment about uninitialized "ob.s.b.encoding".
[Bug gcov-profile/110395] New: GCOV stuck in an infinite loop with large std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110395
Bug ID: 110395
Summary: GCOV stuck in an infinite loop with large std::array
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi!
We are bumping from GCC 7.5.0 to GCC 9.4.0 (Ubuntu 20.04) and observe that GCOV
is stuck when analyzing the following minimal repro code:
#include
#include
template
class StaticVector
{
public:
StaticVector() = default;
void foo(){}
private:
std::array data{};
};
class Foo
{
StaticVector, 4> data_{};
};
int main()
{
Foo f;
return 0;
}
$ g++ --coverage main.cpp
$ ./a.out
$ gcov main.cpp
The problem goes away if I remove the value initialization for std::array in
the StaticVector class (i.e. I leave the member "data" uninitialized).
The same problem happens also on GCC 11
What might be the reason for this?
Thanks!
[Bug gcov-profile/110561] New: gcov counts closing bracket in a function as executable, lowering coverage statistics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561
Bug ID: 110561
Summary: gcov counts closing bracket in a function as
executable, lowering coverage statistics
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 55481
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55481&action=edit
Line 18 wrongly reported as lacking code coverage
Hi!
We are using GCC trunk on Ubuntu 22.04
(d08f2e4f74583e27002368989bba197f8eb7f6d2).
Consider the following code example:
#include
#include
std::string joinPath(std::vector const& path_parts)
{
std::string path{};
for (auto const& path_part : path_parts)
{
if (!path.empty())
{
path += "/";
}
path += path_part;
}
return path;
}
int main()
{
std::vector strings = {"foo", "bar"};
joinPath(strings);
}
Following this process (taken from here:
https://medium.com/@xianpeng.shen/use-gcov-and-lcov-to-perform-code-coverage-testing-for-c-c-projects-c85708b91c78)
to compute coverage:
$ g++ main.cpp --coverage -o main
$ ./main
$ gcov main.cpp
$ lcov --capture --directory . --output-file coverage.info
$ genhtml coverage.info --output-directory out
Leads to a coverage report that says that line 18 is missing code coverage,
which is incorrect since it's just the closing bracket of the function (see
attached picture).
I can see that things go wrong already at the gcov output, so it's not a
rendering/LCOV issue:
$ cat main.cpp.gcov
-:0:Source:main.cpp
-:0:Graph:main.gcno
-:0:Data:main.gcda
-:0:Runs:1
-:1:#include
-:2:#include
-:3:
1:4:std::string joinPath(std::vector const&
path_parts)
-:5:{
1:6:std::string path{};
3:7:for (auto const& path_part : path_parts)
-:8:{
2:9:if (!path.empty())
-: 10:{
1: 11:path += "/";
-: 12:}
-: 13:
2: 14:path += path_part;
-: 15:}
-: 16:
1: 17:return path;
=: 18:}
-: 19:
1: 20:int main()
-: 21:{
2: 22: std::vector strings = {"foo", "bar"};
1: 23: joinPath(strings);
1: 24:}
This problem does not happen always, just on particular cases (I haven't been
able to establish a pattern).
Do you know what could be the problem? Thanks!
[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561 --- Comment #3 from Carlos Galvez --- I forgot to clarify that this bug is _not_ present on gcc 7.5.0 (from where we are bumping), so I believe it's a regression in that regard. Do you still believe it's a duplicate of the bug mentioned above?
[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561
--- Comment #4 from Carlos Galvez ---
To clarify, the .gcov file looks like this (correct) on GCC 7.5.0, which I
believe is newer than the duplicated bug mentioned here:
-:0:Source:main.cpp
-:0:Graph:main.gcno
-:0:Data:main.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include
-:2:#include
-:3:
1:4:std::string joinPath(std::vector const&
path_parts)
-:5:{
1:6:std::string path{};
3:7:for (auto const& path_part : path_parts)
-:8:{
2:9:if (!path.empty())
-: 10:{
1: 11:path += "/";
-: 12:}
-: 13:
2: 14:path += path_part;
-: 15:}
-: 16:
1: 17:return path;
-: 18:}
-: 19:
1: 20:int main()
-: 21:{
2: 22: std::vector strings = {"foo", "bar"};
1: 23: joinPath(strings);
1: 24:}
[Bug gcov-profile/110561] gcov counts closing bracket in a function as executable, lowering coverage statistics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110561 --- Comment #5 from Carlos Galvez --- @Andrew Pinski ping in case you missed my last message. If this were a duplicate but, wouldn't it also happen in GCC 7.5.0?
[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154 --- Comment #6 from Carlos Galvez --- Alright reading Richard's comment I now understand he's not implying current behavior is correct, but rather explaining why it happens. I take it then that this is a bug in Clang then. Thanks for the clarification!
[Bug c++/117154] New: Aggregate initialization with protected destructor in Base class: GCC vs Clang difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154
Bug ID: 117154
Summary: Aggregate initialization with protected destructor in
Base class: GCC vs Clang difference
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Hi,
Consider this code:
struct Base
{
protected:
~Base() = default;
};
struct Derived : Base
{};
int main()
{
Derived d{};
}
https://godbolt.org/z/eh19eorGG
Compiled in C++17 mode, Clang rejects the code:
:12:15: error: temporary of type 'Base' has protected destructor
12 | Derived d{};
| ^
:4:5: note: declared protected here
4 | ~Base() = default;
| ^
While GCC is fine with it. This was filed as an issue to Clang, but the
response was that this was intended behavior:
https://github.com/llvm/llvm-project/issues/81089#issuecomment-1998568533
I'm curious to hear GCC's opinion on the matter, why doesn't GCC reject the
code? It'd be good if both compilers agreed on whether the code is ill-formed
or not.
[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154 --- Comment #3 from Carlos Galvez --- Please note that this ticket is about protected *destructor*. For protected *constructor*, clang has same behavior as GCC. CWG 2244 does not appear to consider this case?
[Bug c++/117046] New: -Wclass-memaccess provides misleading diagnostics on std::memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046
Bug ID: 117046
Summary: -Wclass-memaccess provides misleading diagnostics on
std::memcpy
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Consider this example:
#include
#include
struct Foo
{
int a{123};
};
void f()
{
Foo dst{};
std::array bytes{};
std::memcpy(&dst, &bytes, sizeof(dst));// NOK
std::memcpy(&dst, bytes.data(), sizeof(dst)); // OK
}
https://godbolt.org/z/6hEfa9cd5
Here, GCC complains with following diagnostic:
copying an object of non-trivial type 'struct Foo' ...
It sounds therefore like the problem is that "Foo" is non-trivial. But that's
not actually the problem; std::memcpy accepts non-trivial types, as long as
they are trivially copyable. This is clear from the line below.
The problem was in passing &bytes instead of bytes.data().
Would it be possible to improve the diagnostic?
Thanks!
[Bug c++/117046] -Wclass-memaccess provides misleading diagnostics on std::memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046 --- Comment #6 from Carlos Galvez --- Ah, that might explain it. It would be great to document the additional logic to avoid confusion. It may also help the LLVM folks implementing the same warning with consistent behavior to GCC: https://github.com/llvm/llvm-project/pull/111434
[Bug c++/117046] -Wclass-memaccess provides misleading diagnostics on std::memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046 --- Comment #2 from Carlos Galvez --- I also don't understand why the warning fires at all in this case. Even if we pass &bytes, we are passing an object of type 'std::array' which is trivially-copyable (and even trivial?), so I don't see why it should complain.
[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154 --- Comment #7 from Carlos Galvez --- Hi! I had another look at this an have some follow-up questions: > it looks like GCC already implements the suggested resolution. This does not seem to be the case? The related bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84884 and it's not closed. I can confirm it on Compiler Explorer: https://godbolt.org/z/6EGbovPMq So, if the solution to DR 2244 is not yet implemented, then it feels this is a slightly different issue? Also, DR 2244 talks about a case where we have a "friend" function performing the construction. It seems therefore that having "friend" is important, why else would they add such a constraint? In my example, I don't have "friend", so I'm unsure if DR 2244 applies there.
[Bug c++/117046] -Wclass-memaccess provides misleading diagnostics on std::memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046 --- Comment #8 from Carlos Galvez --- Sorry, I commented on the wrong bug, could some admin please delete my last comment? Thanks!
[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154 --- Comment #8 from Carlos Galvez --- Actually in the patch that would address this issue for Clang (https://reviews.llvm.org/D53860), they mentioned 2277: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0968r0.html#2227 With emphasis: > The destructor for each element of class type is potentially invoked (15.4 > [class.dtor]) from the context where the aggregate initialization occurs. Some more comments from the patch: > I've checked the minutes, and we did indeed discuss that when resolving C++ > DR 2227, and decided that the context for the access check should be the > context of the aggregate initialization, not the context of the class > definition. This makes sense with my very limited knowledge, but I'd like to hear your opinion on 2277. It does feel like a separate issue than 2244.
[Bug c++/117046] -Wclass-memaccess provides misleading diagnostics on std::memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117046 --- Comment #7 from Carlos Galvez --- Actually in the patch that would address this issue for Clang (https://reviews.llvm.org/D53860), they mentioned 2277: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0968r0.html#2227 With emphasis: > The destructor for each element of class type is potentially invoked (15.4 > [class.dtor]) from the context where the aggregate initialization occurs. Some more comments from the patch: > I've checked the minutes, and we did indeed discuss that when resolving C++ > DR 2227, and decided that the context for the access check should be the > context of the aggregate initialization, not the context of the class > definition. This makes sense with my very limited knowledge, but I'd like to hear your opinion on 2277. It does feel like a separate issue than 2244.
[Bug c/117577] New: The compiler flag -w does **not** silence all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117577
Bug ID: 117577
Summary: The compiler flag -w does **not** silence all warnings
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: carlosgalvezp at gmail dot com
Target Milestone: ---
Example:
typedef void (*PFUNC)(int);
void func(double);
int main()
{
PFUNC x = func;
}
Compiling with "gcc -w main.c", I still get:
: In function 'main':
:7:15: error: initialization of 'PFUNC' {aka 'void (*)(int)'} from
incompatible pointer type 'void (*)(double)' [-Wincompatible-pointer-types]
7 | PFUNC x = func;
| ^~~~
Compiler returned: 1
https://godbolt.org/z/s4eo9Wz7z
I can still suppress the warning explicitly via
-Wno-incompatible-pointer-types, but I would expect "-w" to work here, since
this is a warning (not an error) and -w "Inhibit all warning messages" as per
the docs.
I have seen this issue with other warnings as well. It seems like warnings that
are always active by default (e.g. not opted-in via -Wall, etc) cannot be
suppressed via -w.
Why is that?
[Bug c/117577] The compiler flag -w does **not** silence all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117577 --- Comment #4 from Carlos Galvez --- >From a user perspective, it *does* look like a warning, since it's printed as -Wincompatible-pointer-types. Perhaps printing it as -Werror=incompatible-pointer-types would help clarifying it.
[Bug c/117577] The compiler flag -w does **not** silence all warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117577 --- Comment #2 from Carlos Galvez --- Ah, I see now that it is indeed an error by default, not a warning. As you say it would have been clearer if it printed -Werror=incompatible-pointer-types. I agree the behavior is inconsistent with your last example, it'd be great to fix that. Thanks!
[Bug c++/118396] New: Regression: -O1+ leads to reading uninitialized data when virtual destructor is present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396 Bug ID: 118396 Summary: Regression: -O1+ leads to reading uninitialized data when virtual destructor is present Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: carlosgalvezp at gmail dot com Target Milestone: --- Created attachment 60088 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60088&action=edit bug.cpp Hi! We are bumping our GCC install from e9fb6efa1cf542353fd44ddcbb5136344c463fd0 to 979ca3ba366da7177f427e049f67673ec3e35442, and this minimal example (attached) no longer works. Reproducer on Compiler Explorer: https://godbolt.org/z/3e6zfrMEW When using -O1, I see garbage values being read. Valgrind confirms "Conditional jump or move depends on uninitialised value(s)" when reading those values. I have written a couple of comments of changes to the code that make it work as expected. However I don't fully understand why that would be the case, I don't believe there's UB in this snippet, but of course I could be missing something. Looking forward to your feedback, thanks!
[Bug c++/118396] [15 regression] -O1+ leads to reading uninitialized data when virtual destructor is present since r15-6369-gfa99002538bc91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396 --- Comment #17 from Carlos Galvez --- (FYI I'm trying to test this but now I get out-of-memory errors when trying to compile a single .cpp file, will test with a newer patch in case it got fixed)
[Bug c++/118396] [15 regression] -O1+ leads to reading uninitialized data when virtual destructor is present since r15-6369-gfa99002538bc91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396 --- Comment #19 from Carlos Galvez --- I can confirm that recent versions of trunk fixed the problem described in this thread, thank you so much! > Sounds like another regression? I need to run more tests to confirm. It is a very huge file, it could simply be that we were close to the limits of the machine and now GCC does slightly more work and goes over the threshold. Anyhow, off-topic for this issue, I'll open a separate one if needed!
[Bug c++/118396] [15 regression] -O1+ leads to reading uninitialized data when virtual destructor is present since r15-6369-gfa99002538bc91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396 --- Comment #15 from Carlos Galvez --- Thank you for the quick fix! I'll test it right away :)
[Bug c++/118396] [15 regression] -O1+ leads to reading uninitialized data when virtual destructor is present since r15-6369-gfa99002538bc91
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118396 --- Comment #3 from Carlos Galvez --- Thanks for the quick confirmation! Let me know if I can be of help.
