IMA vs tree-ssa

[Mark Mitchell]

>Whereas I think that if this example shows any problem, it is that the
>requirement that all declarations of an object or function have compatible
>type is not explicit about whether the compatibility required is of all 
>the types any of the declarations have at any point in their scope.  That 
>is, as long as there is only one completed type of an object, including 
>the completions of all structure types pointed to within it, recursively, 
>there can be no problem.  In his example, an object might be declared of 
>type struct bar, and struct foo only afterwards completed (in some 
>translation units but not all), and the question would be whether it is 
>undefined if the completions of struct foo are incompatible - remembering 
>it might only get completed outside the scope of the object declared.  Can 
>we say noone would want to implement some form of abstraction this way 
>(struct foo being incomplete in most places, but some calls being 
>dispatched to different translation units with different completions of 
>it, depending on other values in struct bar)?
>  
>
I'm trying to stop debating the issue.

I'm not arguing about what the current standard says; I'm arguing that 
if this example is well-defined, I don't think the commitee intended 
that.  That's one of the common causes of defects: the committee's words 
turn out not to match its intention due to some oversight.  You and Gaby 
and I cannot answer the question of whether or not the commitee intended 
Geoff's example to have defined behavior.  Nor can we answer the 
question of whether or not the commitee would think that, to the extent 
it has defined behavior, that represents a defect in the standard.

I'd appreciate it if you would, rather than trying to convince me, get 
some additional input.  You'd be an excellent choice for that because 
you know the standard very well and write clearly.  You could definitely 
explain the test case and why it is problematic; you could also  offer 
your interpretation and ask whether or not that is what other readers of 
the reflector believe.  The reason I've asked you several times to 
assist in this way is because you would be very good at it.

Are you willing to help in this way?

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com