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


On Tue, 9 Mar 2004, Mark Mitchell wrote:

> 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.

There are many cases of bad coding style for which users will want
warnings but which a conforming implementation is meant to accept
(possibly with such a warning).  Making a conforming implementation
involves making all these strange cases work right.  We don't yet have a
conforming implementation in GCC, either for C90 or C99 (though few users
notice the nonconformance to C90), though I hope in future we will be able
to complete the conforming implementations.

> 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.

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)?

-- 
Joseph S. Myers
jsm@polyomino.org.uk


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