This is the mail archive of the gcc@gcc.gnu.org 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: IMA vs tree-ssa


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


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