--- Comment #16 from jason at gcc dot gnu dot org 2010-05-13 05:23 ---
Subject: Bug 43787
Author: jason
Date: Thu May 13 05:23:14 2010
New Revision: 159352
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159352
Log:
PR c++/43787
gcc:
* gimplify.c (gimplify_expr):
--- Comment #17 from jason at gcc dot gnu dot org 2010-05-13 05:25 ---
Fixed for 4.5.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jason at gcc dot gnu dot org 2010-05-05 16:32 ---
Subject: Bug 43787
Author: jason
Date: Wed May 5 16:32:20 2010
New Revision: 159072
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159072
Log:
PR c++/43787
gcc:
* gimplify.c (gimplify_expr):
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #14 from jason at gcc dot gnu dot org 2010-05-01 00:58 ---
Looks like my patch for 43075 didn't fix things completely.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-19 09:54 ---
(In reply to comment #3)
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.
As far as I can see,
--- Comment #9 from bangerth at gmail dot com 2010-04-19 22:18 ---
Dereferencing the null pointer invokes undefined behavior, independent on
whether the type of the dereferenced pointer is an empty class or not.
Typically, dereferencing NULL results in a trap. GCC simply preserves
this
--- 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-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
--- 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.
--- 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
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-04-19 00:30 ---
Well at least change the summary to say what the issue is about. There is
always a copy constructor for classes including POD in C++.
--
pinskia at gcc dot gnu dot org changed:
What|Removed
12 matches
Mail list logo
