--- 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
--- 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
--- 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
--- 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 ex
--- 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 asse
: 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
--- 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
on: 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
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
--- 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
--- 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'
--- 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
--- 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
--- 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
--- 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_pair(
--- 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
--- 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
--- 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.or
--- 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
tor 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
--- 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
onent: 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
--- 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
--- 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=19686&action=view)
example of code that generates linker error
compiled with ver 4.3.4 g++ and args -std=c++0x
--
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
25 matches
Mail list logo
