IMA vs tree-ssa

[Mark Mitchell]

Joseph S. Myers wrote:

>On Tue, 9 Mar 2004, Mark Mitchell wrote:
>
>  
>
>>However, I don't think there's any point in all of us debating this
>>issue.  We don't agree on the answer, and none of us has a particularly
>>good way of backing up our position.  To me, this idea of multiple
>>completions of the same incomplete type is ghastly.  You, however,
>>believe it is what the standard requires, and apparently that it is also
>>what the committe intended.
>>    
>>
>
>This seems simply to be a difference between C and C++ backgrounds.  
>Types in C do not have linkage; those in C++ do.  I don't know whether
>this is a deliberate difference, but it is a fairly fundamental one.
>  
>
You and Gaby keep telling me this and I believe you.  I worked on C 
stuff for years before I worked on C++ stuff -- I have roughly as much C 
background as C++ background.

I know that CenterLine's error-checking tools would have complained 
about trying to complete the same type in two different ways in a single 
program, and that our stuff was very widely used, including by AT&T in 
tons of code.  Our design priority was to issue no errors that would 
annoy real users (so, for example, we didn't warn about int/long 
mismatches on systems where they were the same size).  Therefore, the 
fact that we did warn about multiple completions and that we did not get 
complaints suggests that either (a) this doesn't happen very often, or 
(b) users consider it to be a bug when informed that it is happened.

>>I would appreciate it if you would communicate with the C committee to
>>find out what they really intend.  Ultimately, it's their opinion that
>>matters.  We can't resolve this issue just by talking among ourselves.
>>    
>>
>
>What is the actual concrete defect here?  (As far as I know the only
>relevant procedure here is sending DRs - there isn't one for "requests to
>identify intent".  Asking the WG14 reflector a question may get answers
>"obviously yes", "obviously no" and "it's obvious, but I won't say which
>way" to the same question, but doesn't get a good indicator of committee
>intent.) 
>
Well, it would get a good indicator of what other experts on C think the 
intent was.  It can't hurt to get more input, so let's get it!   If all 
the replies agree with one position or the other, we'll have a clear 
indicator.

The defect, in my opinion, is that the standard does not say:

  If there exists a translation unit A such that a tagged type named T 
is incomplete in
  that translation unit, then the program has undefined behavior if 
there is more than
  one translation unit where a tagged type named T is complete and any 
of the
  complete types is not compatible with any of the other complete types.

You are very good with wording such things; you might be able to 
wordsmith that statement more accurately than I, even if you do not 
agree with it.

Note that those words do not imply that there may not exist two 
definitions of a tagged type with the same name; just that if so there 
may not be translation units in which that tag type appears as an 
incomplete type.  The intuition is that either the type is being used 
privately in one or more translation units (in which case it is OK for 
multiple types to have the same name) or it is used publicly (in which 
case all definitions must agree).  If you are using the opaque 
(incomplete) type in a header, then all definitions must match.

I believe that the example that Geoff posted is a compelling argument in 
favor of such a rule.  It is hard for me to believe that the C commitee 
intended that the code he posted have defined behavior.  I'm willing to 
shown otherwise, but I'd like to hear  that some collection of commitee 
members agree that this code is valid before committing us to complex 
machinations in the compiler to deal with this corner case.

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