https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96704
Gleb Natapov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96704
--- Comment #1 from Gleb Natapov ---
Ah, those appears to be sentinel iterators.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gleb at scylladb dot com
Target Milestone: ---
The following program fail on the second assert.
#include
#include
int main() {
std::unordered_map x;
auto r = std::views
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95895
--- Comment #1 from Gleb Natapov ---
Created attachment 48783
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48783&action=edit
File that gcc asked to attach
: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gleb at scylladb dot com
Target Milestone: ---
Got an internal compile error:
raft/raft.cc: In member function ‘seastar::future<>
raft::server::drop_leadership(raft::
Version: 10.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gleb at scylladb dot com
Target Milestone: ---
Compiling the code below with -Wall emits:
warn.cc:37:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #27 from Gleb Natapov ---
(In reply to Jakub Jelinek from comment #26)
> (In reply to Gleb Natapov from comment #25)
> > Using Torvald's rwlock would be definitely better that current state, but
> > not as good as per thread lock.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #25 from Gleb Natapov ---
(In reply to Jakub Jelinek from comment #24)
> (In reply to Gleb Natapov from comment #23)
> > I am not sure I agree. 64 lock will take one page of memory, which is
> > negligible amount nowadays and we can d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #23 from Gleb Natapov ---
(In reply to Jakub Jelinek from comment #20)
> (In reply to Gleb Natapov from comment #19)
> > (In reply to Jakub Jelinek from comment #18)
> > > (In reply to Gleb Natapov from comment #16)
> > > > Can you su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #22 from Gleb Natapov ---
(In reply to torvald from comment #21)
> (In reply to Jakub Jelinek from comment #17)
> > (In reply to torvald from comment #15)
> > > > Similarly, the 64 recursive locks in libc, again, significant amount of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #19 from Gleb Natapov ---
(In reply to Jakub Jelinek from comment #18)
> (In reply to Gleb Natapov from comment #16)
> > Can you suggest an alternative to libgcc patch? Use other TLS model?
> > Allocate per thread storage dynamically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #16 from Gleb Natapov ---
Can you suggest an alternative to libgcc patch? Use other TLS model? Allocate
per thread storage dynamically somehow?
About lock array, I tries to use rwlock and the current one is not better than
regular lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #13 from Gleb Natapov ---
I've done it with my version of it which does basically the same. The patch by
itself has no effect on scalability, but in conjunction with this fix for glibc
https://patchwork.ozlabs.org/patch/652301/ I get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #11 from Gleb Natapov ---
Jakub, can you apply your path please? As you've said glibc will also have to
be fixed and I am working on it, but without that patch fixing glibc will not
help either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68297
Gleb Natapov changed:
What|Removed |Added
CC||gleb at scylladb dot com
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72580
Gleb Natapov changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #4 from Gleb Natapov -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72580
Gleb Natapov changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Gleb Natapov -
++
Assignee: unassigned at gcc dot gnu.org
Reporter: gleb at scylladb dot com
Target Milestone: ---
This program fails to compile with "xx.cc:12:11: error: use of deleted function
‘E::E(E&&)’" error. It should use copy constructor instead.
struct E {
int x;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
Gleb Natapov changed:
What|Removed |Added
CC||gleb at scylladb dot com
--- Comment #10
19 matches
Mail list logo
