PR 33407: Avoid TBAA for inlined operator new

[Richard Guenther]

On 18 Jan 2008 07:35:08 -0800, Ian Lance Taylor <iant@google.com> wrote:
> PR 33407 is a test case in which inlining an odd implementation of C++
> operator new produces a case in which we fail to correctly record the
> aliasing dependency between two separate inlined operator new calls.
>
> The issue is that it is possible for two different calls to operator
> new to return the same pointer (in a normal program this would happen
> with an intervening call to operator delete).  We must not interchange
> loads and stores using this pointer.  When operator new is not inlined
> this will never happen, because the function call will force the
> compiler to push out any memory reads or writes.  However, when
> operator new is simple enough to inline, the compiler can see the uses
> of the pointer with different types, and TBAA can kick in.
>
> This patch fixes the problem by marking operator new function decls
> with a new flag DECL_IS_OPERATOR_NEW.  When we inline such a function
> the code marks the result as DECL_NO_TBAA_P, which means that TBAA may
> not be applied.

Thanks for fixing this bug.

> Arguably we should do the same when inlining a call to a function for
> which DECL_IS_MALLOC is set.  Does anybody want to try to create a
> test case for that?  That would make DECL_IS_MALLOC a funny case: the
> attribute means "the return value does not alias anything," but we
> would add the clause "but if the function is inlined, do not use
> TBAA."

A similar case can be constructed with a DECL_IS_MALLOC function.  Though
if you return the same storage twice from such a function you either have
to use the proper machinery to change the dynamic type (use placement
new in C++) or use the exact same dynamic type as for the last object
(as in C the type system is static and does not allow changing the type
of a memory location dynamically).  So I suppose we are safe in that
we can declare non-working cases as invoking undefined behavior.

Richard.