This is the mail archive of the 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)

On 9/29/06, Mark Mitchell <> wrote:
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();
   t = new (buf) T();

are supposed to work.

Yeah. See PR29286 - our placement new is broken, too. What a can of worms :(

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.

Yes - but as C is lacking a conforming way of ending lifetime of an object and stating lifetime of struct Node typed object in the same storage, the memcpy "trick" looks like an appealing workaround here.

Of course I appreciate hints as to what would be C conforming here ;)

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

I agree. Looking at the C standard I see no way to make the pool allocator in the PR conforming. If not refering to dynamic typing of storage as C++ defines (which I believe now should be the model the middle-end uses).


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