[Bug ada/19410] New: ACATS c64106a - valgrind detects wrong code (overlapping memcpy)

[Bug ada/19410] New: ACATS c64106a - valgrind detects wrong code (overlapping memcpy)

[baldrick at free dot fr]

RUN c64106a 
==4601== Memcheck, a memory error detector for x86-linux. 
==4601== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al. 
==4601== Using valgrind-2.3.0.CVS, a program supervision framework for 
x86-linux. 
==4601== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. 
==4601== For more details, rerun with: -v 
==4601== 
 
,.,. C64106A ACATS 2.5 05-01-11 16:41:51 
---- C64106A CHECK USE OF ACTUAL CONSTRAINTS BY UNCONSTRAINED FORMAL 
                PARAMETERS. 
==4601== Source and destination overlap in memcpy(0x52BFC6EC, 0x52BFC6EC, 28) 
==4601==    at 0x1B906AC5: memcpy (mac_replace_strmem.c:113) 
==4601==    by 0x805B772: _ada_c64106a (c64106a.adb:88) 
==4601==    by 0x8049DFC: main (b~c64106a.adb:149) 
==4601== 
==4601== Source and destination overlap in memcpy(0x52BFC664, 0x52BFC664, 28) 
==4601==    at 0x1B906AC5: memcpy (mac_replace_strmem.c:113) 
==4601==    by 0x805BB4C: _ada_c64106a (c64106a.adb:235) 
==4601==    by 0x8049DFC: main (b~c64106a.adb:149) 
==== C64106A PASSED ============================. 
==4601== 
==4601== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 13 from 1) 
==4601== malloc/free: in use at exit: 10280 bytes in 2 blocks. 
==4601== malloc/free: 12 allocs, 10 frees, 11810 bytes allocated. 
==4601== For a detailed leak analysis,  rerun with: --leak-check=yes 
==4601== For counts of detected errors, rerun with: -v 
PASS:   c64106a

-- 
           Summary: ACATS c64106a - valgrind detects wrong code (overlapping
                    memcpy)
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ada
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: baldrick at free dot fr
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug ada/19410] ACATS c64106a - valgrind detects wrong code (overlapping memcpy)

[baldrick at free dot fr]

------- Additional Comments From baldrick at free dot fr  2005-01-12 23:12 -------
ACATS tests C95087A, CXA4009 and CXA4020 show similar failures. 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[pinskia at gcc dot gnu dot org]

------- 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 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);
}

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
          Component|ada                         |middle-end
     Ever Confirmed|                            |1
           Keywords|                            |wrong-code
   Last reconfirmed|0000-00-00 00:00:00         |2005-01-12 23:36:15
               date|                            |
            Summary|ACATS c64106a - valgrind    |Overlapping memcpy with big
                   |detects wrong code          |struct copies (ACATS
                   |(overlapping memcpy)        |c64106a)
            Version|tree-ssa                    |4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[baldrick at free dot fr]

------- 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 = *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).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[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 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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[baldrick at free dot fr]

------- 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  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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[pinskia at gcc dot gnu dot org]

------- 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 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.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[baldrick at free dot fr]

------- 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 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...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[bosch at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |ebotcazou at libertysurf dot
                   |dot org                     |fr
             Status|NEW                         |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)

[ebotcazou at gcc dot gnu dot org]

------- 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                     |Added
----------------------------------------------------------------------------
         AssignedTo|ebotcazou at libertysurf dot|ebotcazou at gcc dot gnu dot
                   |fr                          |org
           Priority|P2                          |P3


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410

[Bug middle-end/19410] Overlapping memcpy with big struct copies

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-09-12 07:12 -------
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.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
         AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410