Re: [tree-ssa] mainline->branch merge status

[Dale Johannesen <dalej at apple dot com>]

On Jan 29, 2004, at 3:25 PM, Andreas Schwab wrote:

> Dale Johannesen <dalej@apple.com> writes:
>
> > On Jan 29, 2004, at 3:12 AM, Andreas Schwab wrote:
> > > This has the same problem.
> > >
> > >    { \
> > >        *(void **) __o->next_free = (void *) datum; \
> > >        __o->next_free += sizeof (void *); \
> > >    } \
> >
> > True, cut and paste error.  But it still has the problems I mentioned
> > before.
>
> Which problems do you mean?

There is an extra load of __o->next_free, so it is not performance 
neutral
(look at assembly code).  And if __o->next_free points at itself (i.e. 
the
first store changes the value of __o->next_free), the result is 
different.

> > > > can happen.  I believe the following is correct, performance 
> > > > neutral,
> > > > and
> > > > standard-conforming:
> > > >
> > > >        {
> > > >        \
> > > >         void ***t = (void ***)&(__o->next_free);
> > > >         \
> > > >          **t = ((void *)datum);
> > > > \
> > > >        (*t)++;
> > > >        \
> > > >       }                                            \
> > >
> > > I think this will break strict aliasing.
> >
> > So does the other way;  *(void **)__o->next_free = ... is exactly 
> > what you
> > can't do.
>
> I don't follow.  __o->next_free is a character pointer, thus can alias 
> all
> other pointers.

I don't think so.   You can reference any object as a char, but it 
doesn't follow
that you can reference a char object as any arbitrary type.   At least 
that's
the way I read it (6.5 in C99).  It may depend on whether the object 
it's
pointing at was actually declared as a char object, or comes from 
malloc()....
they've rewritten this section from C89, not for the better.

> The problem with your version is, IIUC, that it converts
> a (char **) into a (void ***), which cannot alias under the strict
> aliasing rules, and the compiler can assume that (*t)++ does not modify
> __o->next_free.

Yes, I agree.