https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
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=42490
Eelis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10619
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 distributed ov
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
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=57971
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
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 __assi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
ponent: 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=34365&action=edit
Testcase
It was noticed that Boost's iterator_facade incurred a p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
--- Comment #13 from Eelis ---
It's also worth noting that this affects operator== for std::array. :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128
--- Comment #4 from Eelis ---
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 (which it also supports) there.
So I thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128
--- Comment #1 from Eelis ---
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.
:(
: 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=34150&action=edit
testcase
Changing
this-&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #12 from Eelis ---
Ooh, very nice! Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #10 from Eelis ---
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 and butter type like char, I agree it would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
--- Comment #8 from Eelis ---
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 #6 from Eelis ---
Clang's libc++ (which gives the expected result) might be another source of
inspiration.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611
--- Comment #1 from Eelis ---
(With -O3)
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=31524&action=edit
Testcase
The a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11701
--- Comment #2 from Eelis 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. :)
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
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46332
--- Comment #3 from Eelis 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 emitted during
compilation, and has bee
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
Compo
29 matches
Mail list logo
