This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Fix PR tree-optimization/21407

Daniel Berlin wrote:
On Tue, 2005-05-10 at 10:10 -0700, Dale Johannesen wrote:
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:
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.
If i give you a pointer to a field, that would mean you could add or
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.

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 "liberal thinking"

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]