C++ PATCH: Fix PR 13275

[Mark Mitchell]

On Wed, 2003-12-17 at 18:20, Richard Henderson wrote:
> On Wed, Dec 17, 2003 at 06:01:07PM -0800, Mark Mitchell wrote:
> > I know that we presently decompose some things too early, as you say,
> > but I'm not sure how that relates to "offsetof".
> 
> Because if I let &s.x survive in build_unary_op(ADDR_EXPR), then
> "&((type *)0)->x" is not immediately folded to a constant, and that
> breaks uses of the offsetof macro that are outside of functions.

You just have to teach "fold" to fold this stuff, and then call fold
when you convert to an integral type.

> And I think Gaby's point is that it is simply not possible to abuse
> __builtin_offsetof, whereas __offsetof__ could be used to cheat
> in some instance.  In what way, I'm not sure, but ...

It's an internal compiler primitive.  If users try to abuse it, depsite
documentation to the contrary, so be it.

I think Gaby is probably complaining about the fact that ISO C++ says
that the type argument to "offsetof" must be a POD-struct or POD-union. 
We already warn about that, IIRC.  We could certainly do so now that we
have "__offsetof__"; easy as pie to dress up the compiler to do that, if
someone finds a case that we don't presently warn about.

(And, I think there may be a DR about that restriction; it's
unncessarily strict.  Like all C++ compilers of which I am aware, G++
avoids issuing an error unless the member is actually a member of a
virtual base class, in which case the usual way of computing the offset
does not get you a constant value.)

-- 
Mark Mitchell <mark@codesourcery.com>
CodeSourcery, LLC