This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH]: Fix PR tree-optimization/21407
Daniel Berlin wrote:
On Tue, 2005-05-10 at 10:10 -0700, Dale Johannesen wrote:Let me say a little more clearly what dan is getting to here. If we
loose this battle, we are going to have to pull out the type based
aliasing that is in the existing compiler because it is also too
On May 10, 2005, at 9:46 AM, Daniel Berlin wrote:
On Tue, 2005-05-10 at 09:30 -0700, Mark Mitchell wrote:
Daniel Berlin wrote:If i give you a pointer to a field, that would mean you could add or
but if there's
no exemption for character pointers in that case, there should be, at
least in GNU C, where we assume unsegmented memory.
subtract bytes and legally get at any other member of the structure,
containing structure, etc.
I was told by Geoff Keating, and others, that this is not legal in C.
Have I been misinformed? That would be quite sad.
There was quite a bit of discussion of this internal to Apple, and no
agreement was reached. Geoff strongly takes the position you say;
Mike and I disagree. The standard seems unclear.
The real problem from an interprocedural standpoint is that the
containing type could be in some other compilation unit and used in a
very bad way that you can't see, and you won't know to mark it very bad
in the other compilation unit, because the containing type may not exist
at the point of the very bad operation.
Effectively, we'd have to assume all types are guilty until proven
innocent, instead of innocent until proven guilty.
and pessimistic analysis gives you much worse results :(.
Again, if this is the way the world is, this is the way the world is.
It would be quite sad, though.
I can, in compilation unit A declare a bunch of separate structures that
I freely use. In compilation unit B I can declare a union of all of
those structures defined in compilation unit A. Any pointer passing
accross the boundary between compilation units A and B can this freely
scramble any variable defined in compilation unit A.
Thus, our current type based aliasing (and I would argue any type based
aliasing) that does not assume the worst case for any variable whose
address may leave the compilation unit is invalid.