http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
lu_zero at gentoo dot org changed:
What|Removed |Added
CC||lu_zero at gentoo dot org
---
--- Comment #30 from jason at gcc dot gnu dot org 2009-04-14 03:31 ---
Fixed for 4.3, 4.4 and 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from jason at gcc dot gnu dot org 2009-04-14 03:30 ---
Subject: Bug 39480
Author: jason
Date: Tue Apr 14 03:30:12 2009
New Revision: 146020
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146020
Log:
PR c++/39480
* call.c (build_over_call): Don't c
--- Comment #28 from jason at gcc dot gnu dot org 2009-04-13 20:56 ---
Subject: Bug 39480
Author: jason
Date: Mon Apr 13 20:56:45 2009
New Revision: 146013
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146013
Log:
PR c++/39480
* call.c (build_over_call): Don't c
--- Comment #27 from jason at gcc dot gnu dot org 2009-04-13 20:53 ---
Subject: Bug 39480
Author: jason
Date: Mon Apr 13 20:53:34 2009
New Revision: 146011
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146011
Log:
PR c++/39480
* call.c (build_over_call): Don't c
--- Comment #26 from jason at gcc dot gnu dot org 2009-04-13 20:08 ---
I think this actually only comes up at -O0; without optimization we don't try
to expand a call to __builtin_memcpy as a block move because we need TER to
tell us what the real alignment of the operands is. With optim
--- Comment #25 from jason at gcc dot gnu dot org 2009-04-09 16:05 ---
The C++ front end bit of this needs 22488 to be fixed before we can remove the
explicit call to the builtin and go back to using a MODIFY_EXPR. But in the
meantime we can test for pointer equality before the call.
--- Comment #24 from jakub at gcc dot gnu dot org 2009-03-18 10:11 ---
The problem with that is that in most cases you won't be able to prove it and
memmove is certainly more expensive than memcpy and usually isn't even expanded
inline (unless it is optimized into memcpy by proving non-o
--- Comment #23 from fpbeekhof at gmail dot com 2009-03-18 10:04 ---
My last comment (#22) of course does not address issues pointed out by jason in
#18.
Even if "we know that we are sure that either p1 == p2 or *p1 and *p2 do not
overlap because otherwise there would be an alias violat
--- Comment #22 from fpbeekhof at gmail dot com 2009-03-18 09:56 ---
Subject: Re: generated memcpy causes trouble in assignment
jakub at gcc dot gnu dot org wrote:
> --- Comment #20 from jakub at gcc dot gnu dot org 2009-03-18 09:10
> ---
> So let's use memmove on alpha and
--- Comment #21 from rguenth at gcc dot gnu dot org 2009-03-18 09:47
---
For
struct A
{
int i[200];
};
struct A *p1, *p2;
void f()
{
*p1 = *p2;
}
we are sure that either p1 == p2 or *p1 and *p2 do not overlap because
otherwise there would be an alias violation.
--
http://gcc
--- Comment #20 from jakub at gcc dot gnu dot org 2009-03-18 09:10 ---
So let's use memmove on alpha and let targets with sane memcpy not suffer just
because of one dead architecture.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
--- Comment #19 from falk at debian dot org 2009-03-18 09:06 ---
(In reply to comment #18)
> I can't imagine an implementation of memcpy that would break when the two
> addresses are the same, it just doesn't work if one is offset but
> overlapping.
> So the valgrind warning is pedanti
--- Comment #18 from jason at gcc dot gnu dot org 2009-03-18 03:29 ---
I can't imagine an implementation of memcpy that would break when the two
addresses are the same, it just doesn't work if one is offset but overlapping.
So the valgrind warning is pedantically correct, but I think it
--- Comment #17 from paolo dot carlini at oracle dot com 2009-03-17 13:35
---
Jason, could you maybe double check this one too?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
15 matches
Mail list logo
