--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-02-24
17:06 ---
Note that I don't plan to work on this in the very near future, as the problem
is no breaking news and doesn't appear to cause much harm in practice.
--
What|Removed |
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebotcazou at libertysurf dot
|dot org |fr
Status|NEW
--- Additional Comments From baldrick at free dot fr 2005-01-13 10:47
---
Subject: Re: Overlapping memcpy with big struct copies (ACATS c64106a)
> > Would you like me to file a separate report for them? Here is cxa4009 by
> > the way:
>
> Yes please because this is a related issue b
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-13
00:12 ---
(In reply to comment #5)
> Subject: Re: Overlapping memcpy with big struct copies (ACATS c64106a)
>
> On Thursday 13 January 2005 00:57, pinskia at gcc dot gnu dot org wrote:> >
> > Yes it does matter at
--- Additional Comments From baldrick at free dot fr 2005-01-13 00:08
---
Subject: Re: Overlapping memcpy with big struct copies (ACATS c64106a)
On Thursday 13 January 2005 00:57, pinskia at gcc dot gnu dot org wrote:
>
> --- Additional Comments From pinskia at gcc dot gnu dot org
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12
23:57 ---
(In reply to comment #3)
> Subject: Re: Overlapping memcpy with big struct copies (ACATS c64106a)
> > If the source and destination are identical, does it matter if memcpy is
> used? That said, ACATS tests
--- Additional Comments From baldrick at free dot fr 2005-01-12 23:52
---
Subject: Re: Overlapping memcpy with big struct copies (ACATS c64106a)
> This can be reproduced with the following C example:
> struct A
> {
> int a[1024];
> };
> void g(struct A *a, struct A *b)
> {
> *a = *
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-12
23:36 ---
If this is anything, this is a testuite bug:
REC2 := PKG.REC2;
REC2 is passed in:
PKG.CHK_RECTYPE1 (PKG.REC1, PKG.REC2, PKG.REC3);
Or a middle-end one for using memcpy as it as
