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 Fri, 2006-09-29 at 11:22 +0200, Richard Guenther wrote:
> Oh, 6.5 is indeed explicit about memcpy.  Changing all pointer types
> the
> testcase uses for freelist handling to char[sizeof(void*)] would make
> it valid
> but completely ugly to look at.

Actually wait a minute.  Even changing it to that is wrong and here is
why as the effective type in that case is just a character type and not
what you wanted as then you can only access it via a character type :).

Try something like this (note I have not looked at the standard to
figure out if this is valid or not):
extern void abort(void);
struct Foo {
  int a;
  int b;
void *pool;
void grow (void)
  void *mem = __builtin_malloc (4096);
  struct Foo *foo;
  __builtin_memcpy (mem, &pool, sizeof(void*));
  pool = mem;
static inline void *alloc_one (void)
  void *node = pool;
  __builtin_memcpy (&pool, node, sizeof(void*));
  return node;
static inline void dealloc_one (void *p)
  void *node = p;
  __builtin_memcpy (node, &pool, sizeof(void*));
  pool = node;
int main()
  struct Foo* foo = alloc_one();
  foo->a = 0;
  foo->b = -1;
  dealloc_one (foo);
  if (foo->b == -1)  /* Except this is after free so really this
testcase is invalid anyways. */
    abort ();
  return 0;

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.

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