[Bug middle-end/19410] Overlapping memcpy with big struct copies
--- Comment #10 from baldrick at gcc dot gnu dot org 2006-12-01 08:31 --- None of the examples provided in this bug report generate an overlapping memcpy with current gcc. -- baldrick at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19410
[Bug middle-end/19410] Overlapping memcpy with big struct copies
--- 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
[Bug middle-end/19410] Overlapping memcpy with big struct copies (ACATS c64106a)
-- 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)
--- 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 (ACATS c64106a)
--- 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)
--- 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|-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)
--- 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)
--- 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)
--- 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)
--- 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
