Re: Hack in gcc/c-decl.c?

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

Mike Stump <mrs@apple.com> writes:

| On Dec 29, 2005, at 12:16 PM, Gabriel Dos Reis wrote:
| > | > I guess we just have to wait till GCC is miscompiled (probably by
| > | > itself) to see whether the Middle End would cite chapter and
| > verse :-)
| >
| > I suspect that humor does not travel well through emails :-)  Sorry.
| 
| As my 4 year old would say, that's not funny.  :-)
| 
| > I was under the impression that we got some core language issues
| 
| For our purposes, the issue was decided and resolved.  We welcome
| dissenters to take the issue up with the C committee and see if they
| want to clarify the language standard in the way that is yet more
| restrictive than what gcc currently does, if they did, then we can
| decide if we want to take advantage of the latitude granted by the
| language standard.
| 
| Another interesting issue would be:
| 
| struct S {
|      int i;
|      float j;
| } s;
| 
| *(float *)((char*)&s + 4);

I was actually referring to this case (or something to that effect) --
I believe Mark Mitchell was of the opinion that it is undefined
(though, apologies if I misrepresent exactly the opposite of what he
said) and another camp thought it should be defined (or the opposite.)
I don't recall we ever reached an agreement. 

| on a platform that generated the program by printf("%d", offsetof(s,
| j)) to get the 4.  My take, it is valid.  Reasonably, I can see
| people say, but I want the optimizer to be able to notice that field
| j isn't used, and optimize it out.  I'd counter with, the optimizer
| knows that j is at offset 4, and it can see the +4 and `know' the
| field is used.  I would love to see the language in the standard that
| makes this perfectly clear, one way, or the other.

-- Gaby