This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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