[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #10 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 commit r14-11182-g845a0b71c82ad8f1d9967a6f15d10ef402f7f2e5 Author: Jonathan Wakely Date: Tue Dec 10 10:56:41 2024 + libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517] Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes errors for constexpr code. Although Bug 117966 could be fixed by avoiding redundant debug checks in std::span, and Bug 106212 could be fixed by avoiding redundant debug checks in std::array, there are many more cases where similar __glibcxx_requires_valid_range checks fail to compile and removing the checks everywhere isn't desirable. This just disables the __gnu_debug::__check_singular(T*) check during constant evaluation. Attempting to dereference a null pointer will certainly fail during constant evaluation (if it doesn't fail then it's a compiler bug and not the library's problem). Disabling this check during constant evaluation shouldn't do any harm. libstdc++-v3/ChangeLog: PR libstdc++/109517 PR libstdc++/109976 * include/debug/helper_functions.h (__valid_range_aux): Treat all input iterator ranges as valid during constant evaluation. (cherry picked from commit 9616deb23a17ebe81ad89ede191d7f9f752abdec)
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #9 from GCC Commits --- The releases/gcc-14 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1e696cac2baa35f011f85878e76039fc3945d241 commit r14-11181-g1e696cac2baa35f011f85878e76039fc3945d241 Author: Jonathan Wakely Date: Mon Dec 9 17:35:24 2024 + libstdc++: Skip redundant assertions in std::array equality [PR106212] As PR c++/106212 shows, the Debug Mode checks cause a compilation error for equality comparisons involving std::array prvalues in constant expressions. Those Debug Mode checks are redundant when comparing two std::array objects, because we already know we have a valid range. We can also avoid the unnecessary step of using std::__niter_base to do __normal_iterator unwrapping, which isn't needed because our std::array iterators are just pointers. Using std::__equal_aux1 instead of std::equal avoids the redundant checks in std::equal and std::__equal_aux. libstdc++-v3/ChangeLog: PR libstdc++/106212 * include/std/array (operator==): Use std::__equal_aux1 instead of std::equal. * testsuite/23_containers/array/comparison_operators/106212.cc: New test. (cherry picked from commit 3aeb2edee2f9fc39ab77c7e020f09d7204b167ac)
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #8 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:9616deb23a17ebe81ad89ede191d7f9f752abdec commit r15-6126-g9616deb23a17ebe81ad89ede191d7f9f752abdec Author: Jonathan Wakely Date: Tue Dec 10 10:56:41 2024 + libstdc++: Disable __gnu_debug::__is_singular(T*) in constexpr [PR109517] Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes errors for constexpr code. Although Bug 117966 could be fixed by avoiding redundant debug checks in std::span, and Bug 106212 could be fixed by avoiding redundant debug checks in std::array, there are many more cases where similar __glibcxx_requires_valid_range checks fail to compile and removing the checks everywhere isn't desirable. This just disables the __gnu_debug::__check_singular(T*) check during constant evaluation. Attempting to dereference a null pointer will certainly fail during constant evaluation (if it doesn't fail then it's a compiler bug and not the library's problem). Disabling this check during constant evaluation shouldn't do any harm. libstdc++-v3/ChangeLog: PR libstdc++/109517 PR libstdc++/109976 * include/debug/helper_functions.h (__valid_range_aux): Treat all input iterator ranges as valid during constant evaluation.
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #7 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3aeb2edee2f9fc39ab77c7e020f09d7204b167ac commit r15-6125-g3aeb2edee2f9fc39ab77c7e020f09d7204b167ac Author: Jonathan Wakely Date: Mon Dec 9 17:35:24 2024 + libstdc++: Skip redundant assertions in std::array equality [PR106212] As PR c++/106212 shows, the Debug Mode checks cause a compilation error for equality comparisons involving std::array prvalues in constant expressions. Those Debug Mode checks are redundant when comparing two std::array objects, because we already know we have a valid range. We can also avoid the unnecessary step of using std::__niter_base to do __normal_iterator unwrapping, which isn't needed because our std::array iterators are just pointers. Using std::__equal_aux1 instead of std::equal avoids the redundant checks in std::equal and std::__equal_aux. libstdc++-v3/ChangeLog: PR libstdc++/106212 * include/std/array (operator==): Use std::__equal_aux1 instead of std::equal. * testsuite/23_containers/array/comparison_operators/106212.cc: New test.
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #6 from Jonathan Wakely --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671270.html
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 Andrew Pinski changed: What|Removed |Added CC||gnu.ojxq8 at dralias dot com --- Comment #5 from Andrew Pinski --- *** Bug 117966 has been marked as a duplicate of this bug. ***
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
--- Comment #4 from Jonathan Wakely ---
Looks like a dup of PR 85944 since it only happens at global scope. The same
static_assert works fine in a function:
void f()
{
static_assert(p - q != 0);
}
*** This bug has been marked as a duplicate of bug 85944 ***
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212
--- Comment #3 from Jonathan Wakely ---
a.C:39:21: error: non-constant condition for static assertion
39 | static_assert(p - q != 0);
| ~~^~~~
a.C:39:24: in 'constexpr' expansion of 'operator-(p, q).P::operator==(P(0))'
a.C:34:8: in 'constexpr' expansion of 'std::operator==(((const
P*)this)->P::e, .P::e)'
a.C:19:20: error: '(((const int*)(&.P::e.std::array::_M_elems)) == 0)' is not a constant expression
19 | { return __ptr == 0; }
| ~~^~~~
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-07-06
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #2 from Jonathan Wakely ---
(In reply to fiesh from comment #1)
> Oh and this appears to be a regression introduced in GCC 12.
Seems to be a library change in GCC 12 which triggers a pre-existing compiler
bug. This fails with all versions of GCC -std=c++20 but compiles with clang
-std=c++20 and EDG --c++20
namespace std
{
using size_t = decltype(sizeof(0));
template
struct array
{
_Tp _M_elems[_Nm];
constexpr const _Tp*
data() const noexcept
{ return _M_elems; }
};
template
constexpr
bool
__check_singular(_Tp* const& __ptr)
{ return __ptr == 0; }
template
constexpr
bool
operator==(const array<_Tp, _Nm>& __one, const array<_Tp, _Nm>& __two)
{
if (__check_singular(__one.data()))
throw 1;
return &__one == &__two;
}
}
struct P {
constexpr P(int i) : e{i} {}
bool operator==(P const &) const = default;
std::array e;
};
constexpr auto operator-(P lhs, P) { return lhs; }
constexpr P p{1}, q{0};
static_assert(p - q != 0);
[Bug c++/106212] Code becomes non-constexpr with _GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106212 --- Comment #1 from fiesh at zefix dot tv --- Oh and this appears to be a regression introduced in GCC 12.
