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

On May 10, 2005, at 11:07 AM, Mark Mitchell wrote:
I'm sure Geoff and Mike will share their reasoning.

Easier to do in person.

So, I think that the argument for invalidity has to hinge on the fact that "(int*)((char*) &s + offsetof (struct S, j)))" is different from "&s.j", even though the standard says those two expressions have the same type and the same value.

No, you got it wrong.

&s.j == (int *) ((char*) &s + offsetof (struct S, j)) in all ways we can ever detect.

this is not in dispute.

Geoff's contention is that you cannot decrement it to point to before &s.j on the grounds that object, means, the s.j object, and it alone. The notion of object, is one the optimizer comes up with though analysis; it's a runtime thing. Also, one cannot increment a pointer to point far past (the second next field if there where two after j) &s.j, because this is beyond the end of the object, the object j.

I disagree. I think that when the value representation of two pointers are the same, then, there cannot be a difference, unless the standard is exceptionally clear they meant to make a difference; that the object, is the complete object. To me, object means, &s for sizeof (s) bytes. Then trivially, one can wonder around in it all day long, and also, as long as the language mandates that the value representation is the same as &s.m, for any given m, then one can dereference that value representation when converted to a pointer to the type of m and that this is in all ways indistinguishable from * (&s.m).

Apologies to Geoff if I am mis-remembering, I cannot seem to find the thread in my email archive.

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