On Mon, Oct 10, 2011 at 2:17 PM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Mon, Aug 15, 2011 at 2:42 PM, Richard Guenther <rguent...@suse.de> wrote: >> >> The g++.dg/init/copy7.C testcase checks whether the C++ frontend >> guards memcpy it emits via a conditional verifying that src != dst >> because calling memcpy with overlapping source / destination is >> not supported. >> >> The testcase is misguided though (and the C++ frontend was, until >> recently) - the middle-end itself will replace aggregate copies >> with memcpy libcalls if it suits - without such conditional. >> As PR39480 shows (the bug that prompted to "fixing" the C++ frontend), >> the "error" was diagnosed by valgrind, not any real memcpy implemenation. >> >> The argument still holds that no reasonable memcpy implementation >> will reject the src == dest case. Arguing about explicit cache >> write-allocation is moot, as you'd still have to handle the >> case of memcpy (&a, &a+1, 1) correctly - and thus any reasonable >> implementation would handle the src == dest case explicitly if >> that is necessary. >> >> Thus, the following simply removes the now FAILing testcase on >> the basis that it never was PASSing really (as my modified >> C testcases in PR50079 show). If we ever encounter a platform >> that fails for memcpy (&a, &a, ...) and we decide it's not the >> platform that is broken we have to invent a fix in the middle-end >> and (conditionally) guard any libcall block moves. >> >> Comments? Ok to commit? > > Ping? Richard? Jason?
Well, so I went ahead and committed the testsuite patch. Richard.
