Re: [rfc] __builtin_offsetof for c and c++

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

Richard Henderson <rth@redhat.com> writes:

| Passes the testsuite on i686-linux.  I've not smoothed out the edges
| wrt nicer diagnostics.  Someone care to hand me a new C++ test that
| checks for all the edge conditions that we don't look for now?

Thanks for doing this.  I really like your approach.
Some (C++) comments:

   (1) Did you test what would happen in templates?  i.e.,

       template<class T>
         struct X {
            int foo_offset() { return offsetof(T, foo); }
         };  

       struct A {
          int foo;
       };

       int main() { return X<A>().foo_offset(); }

   (2)  For C++, you would need to check for PODness before
        handing off the actual computation to build_offsetof.

        You would probably also need to test whether any of the type
        or member designator is dependent.  I.e. 

          struct X { int ary[38]; };

          struct A {
             template<int N, class T>
               int offset(T*) { return offsetof(typename T::X, ary[N]); }

             template<int N>
               int offset() { return offsetof(X, ary[N]); }
          };

          struct B { typedef ::X X; };

         int main()
         {
             A a;
             assert(a.offset<34>((B*)0) == a.offset<34>());
         }

       That may boil down to substituting into some expression nodes
       in cp/pt.c.  It may be easier to have an OFFSETOF_EXPR node
       for that.   

[...]

| 	* lex.c (reswords): Rename "__offsetof" to "__builtin_offsetof".

I would just name the whole think __offsetof__, i.e. with no __builtin
prefix.

[...]

[...]

| +  finish:
| +   /* We've finished the parsing, now finish with the semantics.  At present
| +      we're just mirroring the traditional macro implementation.  Better 
| +      would be to do the lowering of the ADDR_EXPR to flat pointer arithmetic
| +      here rather than in build_unary_op.  */

I think you first need to check whether type is a POD class-type
before calling build_unraryop.