Recall that C99 DR#314 
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_314.htm> deals with 
cross-translation unit type compatibility issues raised on this list with 
optimizing multiple translation units together.  N1226 
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1226.pdf> further 
discussed the issue.

The conclusion at the London meeting was to leave the DR open and consider 
the matter for the C1x revision (to be discussed tomorrow) rather than 
resolving through the DR process.  There was sympathy for the notion that 
the standard *shouldn't* allow examples such as that of my question 3, 
even if there isn't currently wording with that effect.

(Reportedly papers N522 and N561 from 1995-6 - when the tag compatibility 
rules were worked out - may be relevant but aren't online; something may 
be done about scanning the older papers 1986-96 that were circulated only 
in paper form.)

I propose to send the following wording to Benito for the post-London 
mailing as a proposal for C1x - any comments before I send it?




My aim with DR314 is that it should be possible for an implementation
to combine the translation units of a program into a single internal
representation and optimize that, unifying structure and union types
across translation units where required to be compatible in the
process.

Normally, it is possible to create a single translation unit
equivalent to multiple translation units, after renaming static
variables and functions and structure and union tags.  DR314 question
3 is an example where such renaming is not possible.  My proposal is
to add a requirement that it is possible.

Proposed amendment for C1x:

    6.2.7 after paragraph 2 insert: There shall exist a partition of
    all the structure and union types in the program into disjoint
    classes such that (a) if two types are in the same class, then
    they are compatible and (b) whenever two structure or union types
    are required to be compatible, including by (a), they are in the
    same class.  If there does not exist such a partition, the
    behavior is undefined.

This is intended to be consistent with all the analysis in N1226.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Reply via email to