Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Created attachment 31524
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31524action=edit
Testcase
The attached testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611
--- Comment #1 from Eelis gcc-bugzilla at contacts dot eelis.net ---
(With -O3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
Eelis gcc-bugzilla at contacts dot eelis.net changed:
What|Removed |Added
CC||gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #6 from Eelis gcc-bugzilla at contacts dot eelis.net ---
Clang's libc++ (which gives the expected result) might be another source of
inspiration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #8 from Eelis gcc-bugzilla at contacts dot eelis.net ---
With Clang 3.5, given
struct X: std::tuple { char c; };
I get sizeof(X)==1. Is that not what you mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #10 from Eelis gcc-bugzilla at contacts dot eelis.net ---
I see what you mean! And while stuff with empty types and EBO is IMHO not
nearly as serious as random superfluous bytes that are inserted when you use
tuples of a bread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #12 from Eelis gcc-bugzilla at contacts dot eelis.net ---
Ooh, very nice! Thanks!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46332
Summary: __cxa_demangle yields excess parentheses for function
types
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46332
--- Comment #3 from Eelis gcc-bugzilla at contacts dot eelis.net 2010-11-09
17:26:40 UTC ---
(In reply to comment #2)
I'm pretty sure to have seen this behavior mentioned already...
You may be thinking of bug #36002. That one was about errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46466
Summary: [C++0X] ICE when using constexpr with
-fno-elide-constructors
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11701
--- Comment #2 from Eelis gcc-bugzilla at contacts dot eelis.net 2012-03-22
21:56:17 UTC ---
For what it's worth: as the original reporter, I no longer care about this bug
(or typeof in general), because we now have C++11 with decltype. :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
Eelis gcc-bugzilla at contacts dot eelis.net changed:
What|Removed |Added
CC||gcc
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Created attachment 34150
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34150action=edit
testcase
Changing
this-_M_impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128
--- Comment #1 from Eelis gcc-bugzilla at contacts dot eelis.net ---
Hmm, std::allocator::allocate calls ::operator new, which may be user-defined,
so maybe there is no practical way to detect whether it is really using malloc.
:(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128
--- Comment #4 from Eelis gcc-bugzilla at contacts dot eelis.net ---
Yeah, I noticed that tcmalloc is also way faster, and since tcmalloc barely
over-allocates for the sizes requested by vector, there is no benefit to using
malloc_usable_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
--- Comment #13 from Eelis gcc-bugzilla at contacts dot eelis.net ---
It's also worth noting that this affects operator== for std::array. :(
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Created attachment 34365
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34365action=edit
Testcase
It was noticed that Boost's iterator_facade incurred a performance penalty
(while
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354
Eelis gcc-bugzilla at contacts dot eelis.net changed:
What|Removed |Added
CC||gcc
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
It does:
typedef typename iterator_traits_InputIterator::reference _RefType;
const bool __assignable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57971
Eelis gcc-bugzilla at contacts dot eelis.net changed:
What|Removed |Added
CC||gcc
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Consider:
#include
#include
struct X
{
bool alive = true;
~X() { alive = false; }
explicit operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33952
--- Comment #5 from Eelis ---
(In reply to David Malcolm from comment #4)
> Eelis: FWIW, gcc has a -fmax-errors=n option; I wonder if setting that to 1
> might be a better fit for geordi? (just thinking aloud here).
It also truncates the error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10619
Eelis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42490
Eelis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Both the reservoir sampling and the selection sampling implementations use a
uniform_int_distribution<_Size> to generate integers distribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
Eelis changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
--- Comment #2 from Eelis ---
The testcase was a minimized version of the (imho innocuous looking):
#include
#include
template
std::ostream & operator<<(std::ostream &, std::variant const &);
int main() { std::cout << std::endl; }
++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugzilla at contacts dot eelis.net
Target Milestone: ---
Consider:
template
struct vari
{
static_assert(sizeof...(TT) != 0, "bleh");
};
template struct X {};
void f(void(*)(X));
template v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
29 matches
Mail list logo
