ACATS tests C95087A, CXA4009 and CXA4020 show similar failures. 

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 assumes the two structs are going to point to two diffrent 
positions.

This can be reproduced with the following C example:
struct A
{
  int a[1024];
};
void g(struct A *a, struct A *b)
{
  *a = *b;
}
struct A c;
int main(void)
{
  g(&c, &c);
}

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 = *b;
> }
> struct A c;
> int main(void)
> {
>   g(&c, &c);
> }

If the source and destination are identical, does it matter if memcpy is
used?  That said, ACATS tests cxa4009 and cxa4020 have overlapping memcpy's
where the source and destination are not identical (ACATS c95087a is the same
as c64106a: identical source and destination).

(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 cxa4009 and cxa4020 have overlapping memcpy's
> where the source and destination are not identical (ACATS c95087a is the same
> as c64106a: identical source and destination).

Yes it does matter at least according to the C example.  I was just reducing C64106A, the others are 
most likely a different problem.

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  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 cxa4009 and cxa4020 have overlapping memcpy's
> > where the source and destination are not identical (ACATS c95087a is the same
> > as c64106a: identical source and destination).
> 
> Yes it does matter at least according to the C example.  I was just reducing C64106A, the others are 
> most likely a different problem.

Would you like me to file a separate report for them?  Here is cxa4009 by the way:

RUN cxa4009
==19375== Memcheck, a memory error detector for x86-linux.
==19375== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==19375== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux.
==19375== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==19375== For more details, rerun with: -v
==19375==

,.,. CXA4009 ACATS 2.5 05-01-11 17:12:27
---- CXA4009 Check that the subprograms defined in package
                Ada.Strings.Bounded are available, and that they produce
                correct results, especially under conditions where
                truncation of the result is required.
==19375== Source and destination overlap in memcpy(0x52BFC954, 0x52BFC956, 4)
==19375==    at 0x1B906AC5: memcpy (mac_replace_strmem.c:113)
==19375==    by 0x8055C72: ada__strings__superbounded__super_trim__4 (a-strsup.adb:1662)
==19375==    by 0x8063C85: .827::cxa4009__test_block__b10__trim(void) (a-strbou.ads:790)
==19375==    by 0x8065E81: _ada_cxa4009 (cxa4009.adb:351)
==19375==
==19375== Source and destination overlap in memcpy(0x52BFC954, 0x52BFC956, 6)
==19375==    at 0x1B906AC5: memcpy (mac_replace_strmem.c:113)
==19375==    by 0x8055C72: ada__strings__superbounded__super_trim__4 (a-strsup.adb:1662)
==19375==    by 0x8063C85: .827::cxa4009__test_block__b10__trim(void) (a-strbou.ads:790)
==19375==    by 0x8065F46: _ada_cxa4009 (cxa4009.adb:366)
==19375==
==19375== Source and destination overlap in memcpy(0x52BFC954, 0x52BFC956, 6)
==19375==    at 0x1B906AC5: memcpy (mac_replace_strmem.c:113)
==19375==    by 0x8055C72: ada__strings__superbounded__super_trim__4 (a-strsup.adb:1662)
==19375==    by 0x8063C85: .827::cxa4009__test_block__b10__trim(void) (a-strbou.ads:790)
==19375==    by 0x806600B: _ada_cxa4009 (cxa4009.adb:377)
==19375==
==19375== Source and destination overlap in memcpy(0x52BFC954, 0x52BFC958, 5)
==19375==    at 0x1B906AC5: memcpy (mac_replace_strmem.c:113)
==19375==    by 0x8055C72: ada__strings__superbounded__super_trim__4 (a-strsup.adb:1662)
==19375==    by 0x8063C85: .827::cxa4009__test_block__b10__trim(void) (a-strbou.ads:790)
==19375==    by 0x80660D0: _ada_cxa4009 (cxa4009.adb:387)
==== CXA4009 PASSED ============================.
==19375==
==19375== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 13 from 1)
==19375== malloc/free: in use at exit: 10280 bytes in 2 blocks.
==19375== malloc/free: 17 allocs, 15 frees, 12050 bytes allocated.
==19375== For a detailed leak analysis,  rerun with: --leak-check=yes
==19375== For counts of detected errors, rerun with: -v
PASS:   cxa4009


For the first error, the code in question is (a-strsup.adb):

1662                         Source.Data (1 .. Source.Current_Length) :=
1663                           Source.Data (First .. Last);

where Source.Current_Length = 4, First = 3 and Last = 6.  So indeed the source
and destination overlap (these are strings).  The code seems to perform a direct
call to memcpy.

(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 least according to the C example.  I was just reducing C64106A, the others 
are 
> > most likely a different problem.
> 
> 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 but I think it might be an Ada front-end bug rather than what 
C64106A is which is a middle-end one as shown by the C example.

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 but I think it might be an Ada front-end bug rather than what 
> C64106A is which is a middle-end one as shown by the C example.

I filed a separate bug report for CXA4009 and CXA4020: [Bug ada/19419].

By the way, I've tried to imagine how a memcpy with source==target can cause problems, without much
success.  Any hints? :)  The only thing I could come up with was: if there are two copies of the
same bit of memory (eg: one in cache, the other in main memory; or one in backing store, one in memory),
with one copy being out of date; and the memcpy causing the out-of-date one to be written on top of the
up-to-date one somehow...

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.

Here are 2 equivalent testcases in Ada and C:

procedure p is

  SUBTYPE INT IS INTEGER RANGE 0..1000;

  TYPE RECTYPE (CONSTRAINT : INT := 80) IS
  RECORD
    INTFIELD  : INTEGER;
    STRFIELD  : STRING (1..CONSTRAINT);
  END RECORD;

  REC1  : RECTYPE(1000);

  PROCEDURE COPY_RECTYPE (REC : OUT RECTYPE) is
  begin
    REC := REC1;
  end;

begin
  COPY_RECTYPE (REC1);
end;


struct A
{
  int a[1024];
};

struct A my_a;

void g(struct A *a)
{
  *a = my_a;
}

int main(void)
{
  g(&my_a);
}


The call to "memcpy" is hard-wired in the middle-end (expr.c:1390):

void
init_block_move_fn (const char *asmspec)
{
  if (!block_move_fn)
    {
      tree args, fn;

      fn = get_identifier ("memcpy");
      args = build_function_type_list (ptr_type_node, ptr_type_node,
				       const_ptr_type_node, sizetype,
				       NULL_TREE);

      fn = build_decl (FUNCTION_DECL, fn, args);
      DECL_EXTERNAL (fn) = 1;
      TREE_PUBLIC (fn) = 1;
      DECL_ARTIFICIAL (fn) = 1;
      TREE_NOTHROW (fn) = 1;

      block_move_fn = fn;
    }


I still don't plan to work on this in the near future.

None of the examples provided in this bug report generate
an overlapping memcpy with current gcc.