This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix the one entry mem{{,p}cpy,move,set} optimization aliasing issues (PR middle-end/29272)


Jakub Jelinek wrote:
Hi!

While the PR29272 testcase is IMHO violating the strict aliasing rules
(my reading of 6.5 is that for the heap object the first memcpy call gives the
object struct Node * effective type, so it shouldn't then be accessed as
int)

The "effective type" stuff leads to the what-is-an-object problems. I don't think it's really possible to deduce entirely coherent semantics for these bits from the standard, in all cases. In C++, placement new makes things even more complicated, as things like:


  buf = new char[4096];
  s = new (buf) S();
  s->~S();
  t = new (buf) T();

are supposed to work.

However, I do agree that the testcase in Comment #1 is invalid, as the memcpy in alloc_one gives the memory type the type "struct Node *", but the memory is subsequently accessed as "int". That applies to the testcase in Comment #4 as well.

I think the best way to handle this is conservatively: use alias set zero for all reads/writes from things like memcpy, so that we don't create any no-aliasing expectations in the compiler. I think that trying to get clever about the effective types here is likely to break code, and I'm not at all confident that the rules in the standard are even self-consistent.

2006-09-29 Jakub Jelinek <jakub@redhat.com>

	PR middle-end/29272
	* builtins.c (fold_builtin_memset, fold_builtin_memory_op): Restrict
	single entry optimization to variables and components thereof.

I think this idea is reasonable. Unfortunately, I'd expect one of the cases where this optimization to be most useful to be copying into heap-allocated memory, but correctness trumps optimization...


Would you please make sure that you have a conforming test case to check in with this change, and that you add it to the PR? The current test cases in the PR aren't conforming, so as it stands the PR looks like a non-bug; we should put in a test case which actually is miscompiled so that it's obvious that the PR really is a bug.

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]