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)


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


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