[Bug libstdc++/84671] New: Chrono literals don't accept apostrophe as separator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84671
Bug ID: 84671
Summary: Chrono literals don't accept apostrophe as separator
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: curdeius at gmail dot com
Target Milestone: ---
Created attachment 43547
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43547&action=edit
bug-chrono-literals-apostrophe-repro
Concerned GCC versions: from 5.0.0 onwards (tested up to GCC 8.0.1 trunk from
2018-02-28).
GCC 4.9.3 accepts the code.
Online demo: http://coliru.stacked-crooked.com/a/eed5e2702d1daaa8.
When using UDLs from std::literals::chrono_literals, rejects the use of
apostrophes as delimiters.
E.g.:
```
using namespace std::literals::chrono_literals;
auto ns_ok = 12113ns;
auto ns_fail = 12'113ns;
```
Compiling this code (or precisely the attachment) using `g++ prog.cc
-std=c++14` or any standard from C++14 onwards gives the message:
```
In file included from /opt/wandbox/gcc-head/include/c++/8.0.1/chrono:42,
from prog.cc:1:
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h: In instantiation
of 'struct std::__parse_int::_Number_help<10, 100, '\'', '1', '1', '3'>':
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:195:57:
recursively required from 'struct std::__parse_int::_Number_help<10, 1000, '2',
'\'', '1', '1', '3'>'
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:195:57: required
from 'struct std::__parse_int::_Number_help<10, 1, '1', '2', '\'', '1',
'1', '3'>'
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:208:12: required
from 'struct std::__parse_int::_Number<10, '1', '2', '\'', '1', '1', '3'>'
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:248:12: required
from 'struct std::__parse_int::_Parse_int<'1', '2', '\'', '1', '1', '3'>'
/opt/wandbox/gcc-head/include/c++/8.0.1/chrono:905:67: required from
'constexpr _Dur std::literals::chrono_literals::__check_overflow() [with _Dur =
std::chrono::duration >; char ..._Digits =
{'1', '2', '\'', '1', '1', '3'}]'
/opt/wandbox/gcc-head/include/c++/8.0.1/chrono:961:65: required from
'constexpr std::chrono::nanoseconds
std::literals::chrono_literals::operator""ns() [with char ..._Digits = {'1',
'2', '\'', '1', '1', '3'}; std::chrono::nanoseconds =
std::chrono::duration >]'
prog.cc:5:16: required from here
/opt/wandbox/gcc-head/include/c++/8.0.1/bits/parse_numbers.h:196:42: error:
static assertion failed: integer literal does not fit in unsigned long long
static_assert((type::value / _Pow) == __digit::value,
~^~
```
The problem seems to come from struct _Number_help that does not take
apostrophes '\'' into account
(https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/parse_numbers.h#L188).
[Bug c++/67762] [C++1z] 'not a constant expression" errors only with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67762
--- Comment #8 from Curdeius Curdeius ---
A different (rather small) reproduce.
https://godbolt.org/z/bz9sTd34o
It fails with all the versions of gcc from at least 7 (the above code needs
`auto` in template non-type parameter) to trunk from 2021-11-10.
Hope it helps!
```
#include
#include
#include
namespace detail {
static inline void validate(date::weekday v) noexcept {
(void)v;
assert(v.ok());
}
template
struct date_interval {
using duration_type = Duration;
duration_type begin{InitValue};
[[nodiscard]] constexpr auto begin_value() const noexcept {
if constexpr (GetValue != nullptr) {
return std::invoke(GetValue, begin);
} else {
return begin;
}
}
};
} // namespace detail
using days_interval = detail::date_interval;
int main() {
days_interval days;
return (int)days.begin_value();
}
```
[Bug c++/102740] New: [11.2/12 Regression] Data member not found in struct inside an unnamed union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102740
Bug ID: 102740
Summary: [11.2/12 Regression] Data member not found in struct
inside an unnamed union
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: curdeius at gmail dot com
Target Milestone: ---
Reproduce on godbolt: https://godbolt.org/z/3frPbPj35.
This snippet of code works ok on gcc 11.1, but fails to compile on gcc 11.2 and
trunk (12).
```
typedef struct {
union {
struct {
const void* content;
} put;
};
} op_t;
op_t f(const char* alias) {
return op_t{
.put =
{
.content = alias,
},
};
}
```
The error message (compiled with `-std=c++20` but the standard version seems
irrelevant):
```
: In function 'op_t f(const char*)':
:15:5: error: 'op_t::' has no non-static data member
named 'content'
15 | };
| ^
Compiler returned: 1
```
>From the error message, it seems that the compiler searches for `content` data
member inside the unnamed union and not in the unnamed `put` struct.
[Bug c++/102740] [10/11/12 Regression] Data member not found in struct inside an unnamed union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102740 --- Comment #1 from Curdeius Curdeius --- Also, the bug doesn't appear (or TBH, it's a different bug), when the unnamed union contains a `content` data member. But it seems to be a bug then as well, because it's not what is intended to be initialized. Also, the bug doesn't appear without union.
[Bug c++/102740] [10/11/12 Regression] Data member not found in struct inside an unnamed union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102740
--- Comment #3 from Curdeius Curdeius ---
For other users with this problem, a workaround is to use a named struct. So
here, it would look like:
```
typedef struct {
const void* content;
} put_t;
typedef struct {
union {
put_t put; // named struct
};
} op_t;
op_t f(const char* alias) {
return op_t{
.put =
put_t{ // named explicitly
.content = alias,
},
};
}
```
[Bug c++/105577] New: [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577
Bug ID: 105577
Summary: [12 Regression] ICE in delete_unmarked_insns, at
dce.cc:653
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: curdeius at gmail dot com
Target Milestone: ---
Similar to bug https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90082.
GCC 12.1.0 ICEs when compiling this code with:
```
g++ -DROCKSDB_PLATFORM_POSIX -isystem rocksdb-cloud -isystem
rocksdb-cloud/include -O3 -march=haswell -fnon-call-exceptions -c
rocksdb-cloud/db/db_impl/db_impl_compaction_flush.cc
```
All the three flags are important, as the ICE doesn't happen with -O2, nor
without -march, nor with -march=skylake, but it does happen with microarchs
older than haswell.
ICE doesn't happen without -fnon-call-exceptions either.
Version:
```
$ g++ --version
g++ (GCC) 12.1.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
```
The minimized repro (couldn't do better for the moment, preprocessed source
attached of both minimal repro and the full file attached):
```
#include "db/db_impl/db_impl.h"
namespace ROCKSDB_NAMESPACE {
void DBImpl::InstallSuperVersionAndScheduleWork(
ColumnFamilyData* cfd, SuperVersionContext* sv_context,
const MutableCFOptions& mutable_cf_options) {
if (UNLIKELY(sv_context->new_superversion == nullptr)) {
sv_context->NewSuperVersion();
}
bottommost_files_mark_threshold_ = kMaxSequenceNumber;
for (auto* my_cfd : *versions_->GetColumnFamilySet()) {
bottommost_files_mark_threshold_ = std::min(
bottommost_files_mark_threshold_,
my_cfd->current()->storage_info()->bottommost_files_mark_threshold());
}
}
} // namespace ROCKSDB_NAMESPACE
```
[Bug c++/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 Curdeius Curdeius changed: What|Removed |Added CC||curdeius at gmail dot com --- Comment #1 from Curdeius Curdeius --- Created attachment 52965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52965&action=edit Preprocessed source of the full reproducer
[Bug c++/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #2 from Curdeius Curdeius --- Created attachment 52966 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52966&action=edit Preprocessed source of the minimal reproducer
[Bug rtl-optimization/105577] [12/13 Regression] ICE in delete_unmarked_insns, at dce.cc:653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #4 from Curdeius Curdeius --- Created attachment 52967 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52967&action=edit A slightly reduced case A bit more reduced reproducer. Not sure it helps.
[Bug rtl-optimization/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #17 from Curdeius Curdeius --- Thanks a lot for fixing this quickly!
[Bug c++/116052] New: [15 Regression] ICE in diagnostic_context::diagnostic_impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116052
Bug ID: 116052
Summary: [15 Regression] ICE in
diagnostic_context::diagnostic_impl
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: curdeius at gmail dot com
Target Milestone: ---
An ICE occurs on current trunk (as of 2024-07-23).
It works fine with GCC 14.1.
Godbolt: https://godbolt.org/z/rq67Mnsrr
The code is the example from https://wg21.link/P3090, page 4.
Compiler output:
```
In file included from
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__transform_sender.hpp:21,
from
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__senders.hpp:31,
from
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__as_awaitable.hpp:26,
from
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/execution.hpp:21,
from :5:
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:
In instantiation of 'stdexec::__detail::__env_type_t<_Self, typename decltype
(stdexec::__declval<__detail::__sexpr_apply_t>()(__declval<_Sexpr>(),
stdexec::__declval<__detail::__sexpr_uncurry_fn<__q<__detail::__desc> >
>()))::__tag, _Idx, _Sexpr, typename _ReceiverId::__t>
stdexec::__detail::__receiver<_ReceiverId, _Sexpr, _Idx>::__t::get_env() const
[with _Self =
stdexec::__detail::__receiver,
stdexec::__sexpr<stdexec::{anonymous}::(),
stdexec::{anonymous}::__anon>, stdexec::__muchar (*)[1]>::__t; _ReceiverId =
stdexec::__sync_wait::__receiver; _Sexpr = stdexec::__sexpr<stdexec::{anonymous}::(),
stdexec::{anonymous}::__anon>; _Idx = stdexec::__muchar (*)[1]]':
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:210:11:
required from here
210 | get_env() const noexcept -> __env_type_t<_Self, __tag_t,
_Idx, _Sexpr, _Receiver> {
| ^~~
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:210:11:
error: use of built-in trait '__decay(decltype((stdexec::__sexpr_impl >, true>::__g
> >::get_state)(__declval()(), __declval()(' in function signature; use
library traits instead
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:
In instantiation of 'stdexec::__detail::__env_type_t<_Self, typename decltype
(stdexec::__declval<__detail::__sexpr_apply_t>()(__declval<_Sexpr>(),
stdexec::__declval<__detail::__sexpr_uncurry_fn<__q<__detail::__desc> >
>()))::__tag, _Idx, _Sexpr, typename _ReceiverId::__t>
stdexec::__detail::__receiver<_ReceiverId, _Sexpr, _Idx>::__t::get_env() const
[with _Self =
stdexec::__detail::__receiver,
stdexec::__sexpr<stdexec::{anonymous}::(),
stdexec::{anonymous}::__anon>, stdexec::__muchar (*)[1]>::__t; _ReceiverId =
stdexec::__sync_wait::__receiver; _Sexpr = stdexec::__sexpr<stdexec::{anonymous}::(),
stdexec::{anonymous}::__anon>; _Idx = stdexec::__muchar (*)[1]]':
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:210:11:
required from here
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:210:11:
error: use of built-in trait '__decay(decltype((stdexec::__sexpr_impl >, true>::__g
> >::get_state)(__declval()(), __declval()(' in function signature; use
library traits instead
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:
In instantiation of 'stdexec::__detail::__env_type_t<_Index, typename
__decay(_Ty)::__desc_t::__tag, _Index, _Sexpr, _Receiver>
stdexec::__detail::__op_state<_Sexpr, _Receiver>::__get_env(_Index) const [with
_Index = stdexec::__muchar (*)[1]; _Sexpr = stdexec::__sexpr<stdexec::{anonymous}::(), stdexec::{anonymous}::__anon>;
_Receiver = stdexec::__sync_wait::__receiver::__t]':
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:375:9:
required from here
375 | __get_env(_Index) const noexcept
| ^
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:375:9:
internal compiler error: Segmentation fault
0x273c0c5 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x2749cd5 internal_error(char const*, ...)
???:0
0xbb0c46 mangle_decl(tree_node*)
???:0
0x1709e25 decl_assembler_name(tree_node*)
???:0
0x1732841 assign_assembler_name_if_needed(tree_node*)
???:0
0xe9db5d cgraph_node::analyze()
???:0
0x
[Bug c++/116052] [15 Regression] ICE in diagnostic_context::diagnostic_impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116052 --- Comment #5 from Curdeius Curdeius --- FWIW, there's another similar case where an ICE occurs on gcc trunk but works fine on gcc 14 and clang: https://godbolt.org/z/T8srhKvje. P.S. Thank you Andrew for attaching the preprocessed code.
[Bug c++/116052] [15 Regression] ICE in diagnostic_context::diagnostic_impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116052
--- Comment #6 from Curdeius Curdeius ---
A smaller reproduce: https://godbolt.org/z/YGbdbPqh7:
```
#include
stdexec::sender auto f() {
return stdexec::just() | stdexec::then([](auto... args) {
}); // Removing then makes it compile.
}
int main() {
stdexec::sync_wait(f()); // Removing sync_wait makes it compile.
}
```
I'll try to find an even smaller repro if possible.
[Bug libstdc++/119022] New: ranges::inplace_merge should check for iterator_concept, not iterator_category
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119022
Bug ID: 119022
Summary: ranges::inplace_merge should check for
iterator_concept, not iterator_category
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: curdeius at gmail dot com
Target Milestone: ---
Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070
It's related to the above bug report, but it concerns algorithms, an example is
std::ranges::inplace_merge.
It delegates the work to std::inplace_merge, but for some views (e.g. zip_view,
iota_view), their iterators are of (C++17) iterator_category input_iterator_tag
only, while of (C++20) iterator_concept being possibly higher (e.g.
random_access_iterator_tag if all zipped ranges are random-access).
Reproduce: https://godbolt.org/z/f5b1vh79h
```
#include
#include
#include
#include
int main() {
std::vector a{1, 2, 1, 3, 4, 5, 6};
std::vector b{13, 14, 11, 12, 13, 15, 16, 17};
auto r = std::views::zip(a, b);
static_assert(std::ranges::random_access_range);
static_assert(std::ranges::random_access_range);
static_assert(std::ranges::random_access_range);
std::ranges::rotate(r, r.begin() + 2);
std::ranges::inplace_merge(r, r.begin() + 2);
}
```
It fails on libstdc++, works on libc++.
In libstdc++, `iterator_category` is always used.
In libc++, `iterator_concept` is used for constrained algorithms.
Cf.
https://github.com/llvm/llvm-project/blob/main/libcxx/include/__algorithm/iterator_operations.h#L54
used by
https://github.com/llvm/llvm-project/blob/main/libcxx/include/__algorithm/inplace_merge.h#L134
used by
https://github.com/llvm/llvm-project/blob/main/libcxx/include/__algorithm/ranges_inplace_merge.h#L47
