Re: More function decorations II (pool_allocator, mt_allocator, debug, stl_list)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Wed, Apr 22, 2009 at 9:30 AM, Richard Guenther <rguenther@suse.de> wrote:
> On Wed, 22 Apr 2009, Gabriel Dos Reis wrote:
>
>> Yes, but they also share this:
>>
>> ? ? struct Complex {
>> ? ? ? ?double re;
>> ? ? ? ?double im;
>> ? ? };
>>
>> ? ? Complex* newComplex() {
>> ? ? ? ?Complex* p = (Complex*) malloc(sizeof (Complex));
>> ? ? ? ?p->re = 0;
>> ? ? ? ?p-> im = 0;
>> ? ? }
>>
>> ? ? int main(void) {
>> ? ? ? ?Complex* p = newComplex();
>> ? ? ? ?*(double*)p = 9.0; ? ? // #1
>> ? ? ? ? return p->im;
>> ? ? }
>>
>> I don't think #1 ends the lifetime of ?the object pointed to by
>> `p' either. ?The point here is that you have to factor in together
>> all the various places that allow accessing an object value
>> with different types other than the dynamic of effective types.
>> (3.10/15 in particular).
>
> I always find the "an aggregate or union type ..." clause confusing
> as that suggests it is ok to access double x; via an lvalue of
> type Complex while I am sure the opposite is meant - the lvalue
> is of type of a member of the object type.

Yes, I don't think it was ever in the spirit (or letter that)

      double* p = (double*) malloc(sizeof(double));
      *p = 7.0;
      ((Complex*)p)->re = 90;

was valid.

However, I believe there is no doubt that the program
snippet  I presented is a perfectly valid C and C++ program
(modulo including <stdlib.h>).  It has also been a way to
implement 'single inheritance' in C.

The issue for us, is how to get the optimizer understand the
general rule, and the various exceptions -- and most importantly
the impact of the optimizer taking advantage of it.  An optimizer
that does not have a careful reading of the various chapter&verses
may cause far more damages than no optimizer at all.  On the other
hand, we clearly want optimizations based on non-aliasing as
implied by the standard semantics.

-- Gaby