[Bug c++/11701] Typeof problems in detecting whether its argument is a type or an expression
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. :)
[Bug libstdc++/59611] New: std::copy performs worse than naive implementation when copying a single known byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 Bug ID: 59611 Summary: std::copy performs worse than naive implementation when copying a single known byte Product: gcc Version: 4.9.0 Status: UNCONFIRMED 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 attached testcase shows how using a naive implementation (mycopy) causes gcc to generate better code than using std::copy. (Clang /does/ generate optimal code when using std::copy in this case.)
[Bug libstdc++/59611] std::copy performs worse than naive implementation when copying a single known byte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59611 --- Comment #1 from Eelis --- (With -O3)
[Bug c++/78966] New: Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
Bug ID: 78966
Summary: Unjustified variadic template instantiation
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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 void f(vari);
// if this line is commented out, code compiles fine
template void g(X);
void h() { f(g); }
When compiled with gcc 7.0.0 20161219, the static assert triggers:
prog.cc: In instantiation of 'struct vari<>':
prog.cc:16:15: required from here
prog.cc:4:3: error: static assertion failed: bleh
static_assert(sizeof...(TT) != 0, "bleh");
But there's no reason for vari to be instantiated without arguments here, is
there?
[Bug c++/78966] Unjustified variadic template instantiation
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; }
This gives:
error: invalid use of incomplete type ‘struct std::variant_alternative<0,
std::variant<> >’
I'd be curious to know the rule that makes this ill-formed. Anybody happen to
know it, or the number of the DR (if there is one)?
In any case, feel free to close the ticket if GCC is really correct here. In
that case, sorry for the noise. :)
[Bug c++/78966] Unjustified variadic template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966 Eelis changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Eelis --- Ah, thanks for the explanation! That makes sense. I guess that to avoid this problem, one should adhere to a rule along the lines of: "If you're about to write a function like template R f(X); then if f is potentially overloaded, and X cannot be instantiated with an empty pack, you better write f as: template R f(X) because otherwise calls to those other fs may end up requiring X to be instantiable with an empty pack." I now use this workaround for my operator<< for std::variant. Closing.
[Bug c++/33952] -Wfatal-errors truncates multi-line error messages.
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 in the testcase.
[Bug libstdc++/77994] New: std::sample uses incorrect integer types internally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77994 Bug ID: 77994 Summary: std::sample uses incorrect integer types internally Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: 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 over the population size, but _Size is merely the type of the user-supplied argument specifying the desired selection size, and that type may not be large enough to represent integers distributed over the population size. The selection sampling implementation also uses _Size for __unsampled_sz, which is incorrect for the same reason.
[Bug c++/10619] Error message for no matching function calls does not list explicitly-specified template arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10619 Eelis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Eelis --- GCC now emits additional diagnostics explaining why the candidate f could not be used, which is exactly what I wanted. Thanks!
[Bug c++/42490] using-directive in namespace doesn't work properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42490 Eelis changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Eelis --- Seems to be fixed, thanks!
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 Eelis changed: What|Removed |Added CC||gcc-bugzilla at contacts dot eelis ||.net --- Comment #2 from Eelis --- Another manifestation of this is that sizeof(pair,pair>) == 4 while sizeof(tuple,tuple>) == 5 (!!). I think that at the moment, GCC users are best advised to avoid using stdlib tuples if efficiency is a concern.
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
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.
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
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?
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
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 good to file a ticket in http://llvm.org/bugs/ if there isn't one already. :)
[Bug libstdc++/56785] std::tuple of two elements does not apply empty base class optimization when one of its elements is a std::tuple with two elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56785 --- Comment #12 from Eelis --- Ooh, very nice! Thanks!
[Bug c++/68003] New: Variable declared in condition in for loop is destroyed too soon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68003
Bug ID: 68003
Summary: Variable declared in condition in for loop is
destroyed too soon
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
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 bool() const { return true; }
} ;
int main()
{
for(int i = 0; X x = X(); assert(x.alive))
if (++i == 3)
break;
else
std::cout << i << std::endl;
}
When compiled with gcc trunk, the program outputs:
1
a.out: t.cpp:14: int main(): Assertion `x.alive' failed.
When compiled with clang trunk, the program outputs:
1
2
[Bug c++/64450] New: Optimize 0>=p-q to q>=p for char*p,*q;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64450 Bug ID: 64450 Summary: Optimize 0>=p-q to q>=p for char*p,*q; Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: 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 performance penalty (while it should ideally be zero-overhead), which results from the fact that GCC does not optimize 0>=p-q to q>=p for char*p,*q;. See attachment. This probably applies to > and < and <= as well.
[Bug c++/59354] Unexpected result in g++ when casting int to char from an stl vector to an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59354
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #1 from Eelis ---
This is not specific to std::vector and not specific to C++.
C testcase:
#include
#include
int main()
{
uint32_t a[256] = {};
uint8_t b[1000] = {};
for(int i = 0; i != 256; ++i)
a[i] = i % 5;
for (int z = 0 ; z < 16; z++)
for (int y = 0 ; y < 4; y++)
for (int x = 0 ; x < 4; x++)
b[y * 64 + z*4 + x] = a[z * 16 + y * 4 + x];
printf("%d\n", b[4]);
return 0;
}
Prints '4' without -mno-sse, prints '1' with -mno-sse.
[Bug libstdc++/64476] New: std::uninitialized_copy tests assignability the wrong way, resulting in performance pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64476 Bug ID: 64476 Summary: std::uninitialized_copy tests assignability the wrong way, resulting in performance pessimization Product: gcc Version: 5.0 Status: UNCONFIRMED 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 = is_assignable<_ValueType1, _RefType>::value; but should do: typedef typename iterator_traits<_ForwardIterator>::reference _RefType; const bool __assignable = is_assignable<_RefType, _ValueType1>::value;
[Bug c++/57971] Improve copy elision when returning structs by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57971
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #1 from Eelis ---
struct foo { foo(); foo(foo const &); };
foo bar();
foo fast(bool b) {
if (b) return foo();
return bar();
}
/* produces (with -O3):
_Z4fastb:
.LFB0:
testb%sil, %sil
pushq%rbx
movq%rdi, %rbx
jne.L6
call_Z3barv
movq%rbx, %rax
popq%rbx
ret
.p2align 4,,10
.p2align 3
.L6:
call_ZN3fooC1Ev
movq%rbx, %rax
popq%rbx
ret
*/
foo slow(bool b) {
if (b) return foo();
foo f = bar();
return f;
}
/* produces (with -O3):
_Z4slowb:
.LFB1:
pushq%rbx
movq%rdi, %rbx
subq$16, %rsp
testb%sil, %sil
jne.L11
leaq15(%rsp), %rdi
call_Z3barv
leaq15(%rsp), %rsi
movq%rbx, %rdi
call_ZN3fooC1ERKS_
addq$16, %rsp
movq%rbx, %rax
popq%rbx
ret
.p2align 4,,10
.p2align 3
.L11:
call_ZN3fooC1Ev
addq$16, %rsp
movq%rbx, %rax
popq%rbx
ret
*/
[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12086
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #11 from Eelis ---
This bug means that for
struct X { char a[8]; };
bool f(X x, X y) { return __builtin_memcmp(x.a, y.a, 8); }
gcc emits:
subq$40, %rsp
.cfi_def_cfa_offset 48
movl$8, %edx
movq%rdi, 16(%rsp)
leaq16(%rsp), %rdi
movq%rsi, (%rsp)
movq%rsp, %rsi
callmemcmp
testl %eax, %eax
setne %al
addq$40, %rsp
.cfi_def_cfa_offset 8
ret
while clang emits:
movq%rdi, -8(%rsp)
movq%rsi, -16(%rsp)
cmpq%rsi, -8(%rsp)
setne%al
retq
(which is still suboptimal due to llvm bug #20673).
[Bug libstdc++/64128] New: Let vector take advantage of malloc_usable_size for malloc-using allocators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64128 Bug ID: 64128 Summary: Let vector take advantage of malloc_usable_size for malloc-using allocators Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: 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->_M_impl._M_end_of_storage = __new_start + __len; to this->_M_impl._M_end_of_storage = __new_start + malloc_usable_size(__new_start) / sizeof(value_type); in vector.tcc makes the runtime of the attached program drop from 0.35 seconds to 0.24 seconds on my machine, a 31% reduction. This shows there is low hanging fruit for a very common operation (vector::push_back). A proper implementation would of course only do this for allocators that are known to be malloc frontends. :)
[Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators
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. :(
[Bug libstdc++/64128] Let vector take advantage of malloc_usable_size for malloc-using allocators
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 think the bottom line is indeed: just don't use glibc malloc, because it's very slow.
[Bug middle-end/12086] memcmp(i,j,4) should use word (SI) subtraction
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. :(
[Bug libstdc++/46332] New: __cxa_demangle yields excess parentheses for function types
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
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-bugzi...@contacts.eelis.net
Consider:
#include
#include
#include
int main()
{
std::cout <<
abi::__cxa_demangle(typeid( void() ).name(), 0, 0, 0) << '\n';
}
The output is "void ()()", but it should really just be "void ()". If "void
()()" had any meaning at all, it would denote the type of a function returning
a function, but of course that's not valid C++.
The same problem can also be seen by trying to compile and link the following
program:
template void f();
int main() { f(); }
This produces:
undefined reference to `void f()'
Here, too, "void ()()" is wrong and should just be "void ()".
[Bug other/46332] __cxa_demangle yields excess parentheses for function types
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 been fixed. This time it's about errors emitted during linking (and demangling explicitly). :)
[Bug c++/46466] New: [C++0X] ICE when using constexpr with -fno-elide-constructors
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
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gcc-bugzi...@contacts.eelis.net
Compiling
struct S { bool b; };
constexpr S f() { return S{true}; }
static_assert(f().b, "");
with
g++ -std=c++0x -fno-elide-constructors
results in
t.cpp:3:26: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Omitting -fno-elide-constructors makes the problem go away.
I'm using GCC svn r166710.
[Bug c++/96555] "template argument involves template parameter(s)" with dot or arrow operator in partial specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96555
Eelis changed:
What|Removed |Added
CC||gcc-bugzilla at contacts dot
eelis
||.net
--- Comment #2 from Eelis ---
The following slightly simpler testcase is also accepted by clang and rejected
by gcc with the same "involves template parameter" error:
template
struct X;
template
struct X {};
