[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #5 from navin dot kumar at gmail dot com 2010-08-07 15:25 --- Hi Richard, Your explanation doesn't explain why foo1 would emit poorer assembly than foo3. Or for that matter why fooA would emit poorer assembly than fooB. In the case of foo1, foo3, fooA, and fooB, dereferencing occurs first, before casting. Yet only foo3 and fooB generate optimal assembly (so gcc is clearly capable of outputting the desired asm). This is all at -O3, where -fdelete-null-pointer-checks is already enabled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #7 from navin dot kumar at gmail dot com 2010-08-07 16:22 --- Richard, if you can't derive non-NULL-ness from X y = *x, how do foo3 and fooB avoid the null check? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c++/45221] missed optimization with multiple bases and casting
--- Comment #10 from navin dot kumar at gmail dot com 2010-08-07 17:27 --- Richard, correct references in C++ cannot bind to NULL. So gcc should derive non-NULL-ness when the argument is a reference. It seems to correctly do this in the case of foo3 and fooB, but fails to do so for foo1 and fooA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c++/45221] New: missed optimization on casting pointers even under -O3
Even under -O3, the assembly generated for foo1 and foo2 is vastly inferior to
the one generated for foo3, even though code-wise all three are identical.
class Base1 { int data; };
class Base2 { int data; };
class Derived : public Base1, public Base2 { public: int data; };
int foo1(Base2* x) {
return static_castDerived(*x).data;
}
int foo2(Base2* x) {
return static_castDerived*(x)-data;
}
int foo3(Base2* x) {
Base2 y = *x;
return static_castDerived(y).data;
}
--
Summary: missed optimization on casting pointers even under -O3
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: navin dot kumar at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c++/45221] missed optimization on casting pointers even under -O3
--- Comment #1 from navin dot kumar at gmail dot com 2010-08-07 01:29 --- The assembly generated for foo1 foo2 (under -O3) are identical: leaq-4(%rdi), %rdx xorl%eax, %eax testq %rdi, %rdi cmovne %rdx, %rax movl8(%rax), %eax ret The assembly generated for foo3 is the most optimal: movl4(%rdi), %eax ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug c++/45221] missed optimization with multiple bases and up casting and dereferencing
--- Comment #3 from navin dot kumar at gmail dot com 2010-08-07 02:27
---
The poor optimization does seem to stem from multiple-inheritance (and gcc
trying to preserve nulls across casts). But it's not just upcast; even with
downcasts slow assembly is generated. Take this example:
Base2* fooA(Derived* x)
{
Base2 y = *x;
return y;
}
Base2* fooB(Derived* x) {
Derived x2 = *x;
Base2 y = x2;
return y;
}
Both fooA and fooB are funtionally identical.
Yet the assembly generated for fooA is:
leaq4(%rdi), %rdx
xorl%eax, %eax
testq %rdi, %rdi
cmovne %rdx, %rax
ret
and the assembly generated for fooB is:
leaq4(%rdi), %rax
ret
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45221
[Bug libstdc++/43917] [C++0x] std::swap not working
--- Comment #3 from navin dot kumar at gmail dot com 2010-04-28 17:43
---
Are you compiling with -std=c++0x or without? It compiles fine without the
-std=c++0x flag. The issue is when it is supplied.
Look at line 134 of include/c++/4.5.0/bits/stl_pair.h; inside a #ifdef
__GXX_EXPERIMENTAL_CXX0X__ tag there is the following function:
void
swap(pair __p)
{
using std::swap;
swap(first, __p.first);
swap(second, __p.second);
}
The compiler error stems from trying to pass a pair l-value reference to
pair.
Here's the compiler error with line numbers:
include/c++/4.5.0/bits/stl_pair.h: In function void std::swap(std::pair_T1,
_T2, std::pair_T1, _T2) [with _T1 = std::basic_stringchar, _T2 =
std::basic_stringchar]:
test.cpp:8:19: instantiated from here
include/c++/4.5.0/bits/stl_pair.h:187:7: error: cannot bind
std::pairstd::basic_stringchar, std::basic_stringchar lvalue to
std::pairstd::basic_stringchar, std::basic_stringchar
include/c++/4.5.0/bits/stl_pair.h:134:7: error: initializing argument 1 of
void std::pair_T1, _T2::swap(std::pair_T1, _T2) [with _T1 =
std::basic_stringchar, _T2 = std::basic_stringchar, std::pair_T1, _T2 =
std::pairstd::basic_stringchar, std::basic_stringchar ]
--
navin dot kumar at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|WORKSFORME |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43917
[Bug libstdc++/43916] New: std::swap not working with -std=c++0x
Simple programs like the following do not compile under -std=c++0x on GCC 4.5.0
- due to the new GCC enforcement of C++0x rules regarding l-values not being
allowed to bind to .
#include iostream
#include math.h
int main(int argc, char** argv)
{
std::pair std::string, std::string x(hello, world);
std::pair std::string, std::string y(test, 123);
std::swap(x, y);
std::cout x.first ' ' x.second std::endl;
return 0;
}
Compiler output:
In function void std::swap(std::pair_T1, _T2, std::pair_T1, _T2) [with
_T1 = std::basic_stringchar, _T2 = std::basic_stringchar]:
error: cannot bind std::pairstd::basic_stringchar, std::basic_stringchar
lvalue to std::pairstd::basic_stringchar, std::basic_stringchar
error: initializing argument 1 of void std::pair_T1,
_T2::swap(std::pair_T1, _T2) [with _T1 = std::basic_stringchar, _T2 =
std::basic_stringchar, std::pair_T1, _T2 =
std::pairstd::basic_stringchar, std::basic_stringchar ]
Likely related to bug# 43785
--
Summary: std::swap not working with -std=c++0x
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: navin dot kumar at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43916
[Bug libstdc++/43917] New: [C++0x] std::swap not working
Simple programs like the following do not compile under -std=c++0x on GCC 4.5.0
- due to the new GCC enforcement of C++0x rules regarding l-values not being
allowed to bind to .
#include iostream
#include math.h
int main(int argc, char** argv)
{
std::pair std::string, std::string x(hello, world);
std::pair std::string, std::string y(test, 123);
std::swap(x, y);
std::cout x.first ' ' x.second std::endl;
return 0;
}
Compiler output:
In function void std::swap(std::pair_T1, _T2, std::pair_T1, _T2) [with
_T1 = std::basic_stringchar, _T2 = std::basic_stringchar]:
error: cannot bind std::pairstd::basic_stringchar, std::basic_stringchar
lvalue to std::pairstd::basic_stringchar, std::basic_stringchar
error: initializing argument 1 of void std::pair_T1,
_T2::swap(std::pair_T1, _T2) [with _T1 = std::basic_stringchar, _T2 =
std::basic_stringchar, std::pair_T1, _T2 =
std::pairstd::basic_stringchar, std::basic_stringchar ]
Likely related to bug# 43785
--
Summary: [C++0x] std::swap not working
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: navin dot kumar at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43917
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #10 from navin dot kumar at gmail dot com 2010-04-19 14:53 --- However, what would make_pair have deduced its T1 and T2 to be in this example? My impression was make_pair(x,y) would have deduced T1=uint32_t and T2=uint32_t. Therefore, make_pairuint32_t,uint32_t(x,y) should be synonymous. The part that is confusing is if I do a diff on bits/stl_pair.h between GCC4.4.2 and GCC4.5.0, the constructor has not changed. Yet it compiles with -std=c++0x on GCC4.4.2 but errors with -std=c++0x on GCC4.5.0 (which is why I opened it up as a bug report to c++ initially rather than libstdc++). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug libstdc++/43785] [4.5/4.6 Regression] very basic regression in std::make_pair
--- Comment #11 from navin dot kumar at gmail dot com 2010-04-19 14:54 --- typo: constructor has not changed in the above post should be function has not changed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug c++/43787] [4.5/4.6 Regression] memory copy of empty class (sizeof is one)
--- Comment #10 from navin dot kumar at gmail dot com 2010-04-19 23:44 --- Wolfgang, The opening post was a bad example, and it unfortunately is drawing attention. I agree, it is invalid code for deferencing a NULL pointer. However, please see my other posts, detailing how the actual issue is a performance bug (missed optimization) regression in GCC 4.5.0 for the following (valid) code: empty_t a; empty_t b = a; GCC4.4.2 did not do any memory copying in the above example, but GCC4.5.0 does. -- navin dot kumar at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43787] [4.5/4.6 Regression] memory copy of empty class (sizeof is one)
--- Comment #11 from navin dot kumar at gmail dot com 2010-04-20 00:11 --- It seems okay - at -O3 gcc 4.5.0 is correctly avoiding the memory copy. This used to happen at the default optimization for gcc 4.4.2, but that's fine. I'm closing the bug. -- navin dot kumar at gmail dot com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43787] [4.5/4.6 Regression] memory copy of empty class (sizeof is one)
--- Comment #12 from navin dot kumar at gmail dot com 2010-04-20 00:51 --- (In reply to comment #11) It seems okay - at -O3 gcc 4.5.0 is correctly avoiding the memory copy. This used to happen at the default optimization for gcc 4.4.2, but that's fine. I'm closing the bug. Sorry, I take that back, even at -O3 gcc4.5.0 is still memory copying. -- navin dot kumar at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43787] [4.5/4.6 Regression] memory copy of empty class (sizeof is one)
--- Comment #13 from navin dot kumar at gmail dot com 2010-04-20 01:13
---
Example:
//test.cc
class empty_t { };
empty_t foo2(empty_t* x) throw() {
return *x;
}
When I do a diff between the assembly generated for test.cc by 4.4.3 and 4.5.0
I get the following:
gcc443:
xorl %eax,%eax
gcc450:
movzbl (%rdi), %eax
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43785] New: very basic regression in std::make_pair
in GCC 4.4.2, the following compiles, but in GCC 4.5.0, it does not:
#include iostream
#include math.h
int main(int argc, char** argv)
{
uint32_t x = 1;
uint32_t y = 2;
std::make_pairuint32_t,uint32_t(x, y);
return 0;
}
In GCC4.5.0 the error is:
test.cpp: In function int main(int, char**):
test.cpp:8:40: error: no matching function for call to make_pair(uint32_t,
uint32_t)
--
Summary: very basic regression in std::make_pair
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: navin dot kumar at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug c++/43785] very basic regression in std::make_pair
--- Comment #1 from navin dot kumar at gmail dot com 2010-04-18 16:43 --- Arguments: g++ -Wall -std=c++0x -- navin dot kumar at gmail dot com changed: What|Removed |Added CC||navin dot kumar at gmail dot ||com Known to fail||4.5.0 Known to work||4.4.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43785
[Bug c++/43787] New: regression on copy-constructor of empty class
The following code compiles runs fine on GCC 4.4.2, it compiles segfaults
on GCC 4.5.0, arguments: -std=c++0x -g -fno-inline
#include iostream
#include math.h
#include type_traits
class empty_t {};
static_assert(std::is_emptyempty_t::value, sanity check);
int main(int argc, char** argv)
{
empty_t* x = NULL;
empty_t y = *x;
return 0;
}
Core stack trace:
Program terminated with signal 11, Segmentation fault.
#0 0x0040060b in main (argc=1, argv=0x7fff9ae7e848) at test.cpp:11
11 empty_t y = *x;
--
Summary: regression on copy-constructor of empty class
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: navin dot kumar at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class
--- Comment #2 from navin dot kumar at gmail dot com 2010-04-18 18:31 --- Only GCC4.5.0 is emitting a copy-constructor that copies 1 byte of data (probably because sizeof(empty_t) == 1 according to the C++ ABI). The copy-constructor *should* be a noop, and indeed GCC4.4.2 issues a noop for copying empty classes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class
--- Comment #3 from navin dot kumar at gmail dot com 2010-04-18 18:33 --- At the very least, you'd agree that it's a performance bug to be copying bytes from memory when the class is empty. At the severe use-case, it breaks existing code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class
--- Comment #5 from navin dot kumar at gmail dot com 2010-04-19 00:22 --- Andrew, What about the performance bug? empty_t x; // line1 empty_t y = x; // line2 Line2 should not result in copying memory for empty classes. And that was the old behavior pre-4.5.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/43787] [4.5/4.6 Regression] regression on copy-constructor of empty class
--- Comment #6 from navin dot kumar at gmail dot com 2010-04-19 00:22 --- Andrew, What about the performance bug? empty_t x; // line1 empty_t y = x; // line2 Line2 should not result in copying memory for empty classes. And that was the old behavior pre-4.5.0 -- navin dot kumar at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43787
[Bug c++/42840] New: const-ref argument in a variadic template arglist is mishandled
When a static-const primitive is passed as a const-ref argument to function
with a variadic template arglist, GCC generates code that references the
static-const primitive, and optimizes away the static-const primitive,
resulting in a undefined reference linker error.
/* Start of Example */
class Foo {
public:
template typename... T
static void foo(const T... blah) { }
};
class Test {
public:
static const int tmp = 1;
};
int main(int argc, char** argv) {
Foo::foo(Test::tmp); // THIS COMPILES BUT LINKER FAILS
//Foo::foo(static_castint(Test::tmp)); // THIS COMPILES AND LINKS FINE
}
/* END OF EXAMPLE */
LINKER ERROR:
/tmp/ccfV1opu.o: In function `main':
tmp.cc:(.text+0x10): undefined reference to `Test::tmp'
collect2: ld returned 1 exit status
Since static cast of the static-const int primitive to an int fixes the
problem, it's clear that GCC is somehow mishandling how it optimizes away
Test::tmp even though it's being used as a const int in Foo::foo(...)
--
Summary: const-ref argument in a variadic template arglist is
mishandled
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: navin dot kumar at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42840
[Bug c++/42840] const-ref argument in a variadic template arglist is mishandled
--- Comment #1 from navin dot kumar at gmail dot com 2010-01-22 03:32 --- Created an attachment (id=19686) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19686action=view) example of code that generates linker error compiled with ver 4.3.4 g++ and args -std=c++0x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42840
[Bug c++/42840] const-ref argument in a variadic template arglist is mishandled
--- Comment #2 from navin dot kumar at gmail dot com 2010-01-22 03:39 --- Ignore. Close bug. Found the issue here: http://hellewell.homeip.net/phillip/blogs/index.php?entry=entry060314-00 -- navin dot kumar at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42840
