[PATCH] Fix the one entry mem{{,p}cpy,move,set} optimization aliasing issues (PR middle-end/29272)
Richard Guenther
rguenther@suse.de
Fri Sep 29 13:06:00 GMT 2006
On Fri, 29 Sep 2006, Paolo Bonzini wrote:
> > Actually wait a minute a second time, these testcases are all invalid
> > because other reasons. We are using memory after they have been
> > "dealloced" Richard, do you have an example which does not have that
> > issue because it seems like they are all invalid.
>
> How in the world can the C compiler know what is "dealloc"-ing? There is no
> such thing as __attribute__ ((free)) and even if it was there, it's not
> attached to dealloc_one. As far as the compiler is concerned, the code is
> just playing with a linked list.
>
> The only way in which freeing affects aliasing, is that malloc will return
> something that does not alias anything, and thus overwrites of the malloc-ed
> object via a dangling pointer will be missed by the aliasing machine. That
> is:
>
> free (a);
> b = malloc (10); /* suppose b = a */
> b->x = 3;
> a->x = 5; /* dangling pointer, but not invalid code */
> return b->x; /* compiler may return 3 */
Yes, likewise with
#include <new>
struct Foo { int i; };
struct Bar { void *p; };
int foo(void)
{
Foo *f = new Foo;
f->i = 1;
Bar *b = new (f) Bar;
b->p = 0;
f = new (f) Foo;
return f->i;
}
the compiler can (and will atm) return 1. Now I failed to make a
valid (not undefined) testcase that makes the current in-place std::new
implementation generate wrong-code...
Richard.
--
Richard Guenther <rguenther@suse.de>
Novell / SUSE Labs
More information about the Gcc-patches
mailing list