> nothing prevent alias analysis to be performed regardless of the TU boundaries
Standard conformance does. You know, that principle in the name of which the alias-breaking optimizations are done in the first place.
The "as if" principle (there is only one) means that optimized code produces the same results as the abstract semantics (under a certain set of requirements of what it means for the abstract and actual semantics to agree).
The separation between translation phase 7 and 8 is part of that abstract language semantics.
> And compilers are doing it.
GCC currently only does optimizations across translation unit boundaries when it is told via special options, and only for the .o files which are designated as participating in it. This is no different from using __attribute___ or __asm__.
Well, in the model, there is no such thing as effective type of objects loosing their power at TU boundaries, and otherwise no relationship defined between effective types and linkage. An implementation that tags all accesses to dynamically check/enforce the effective type rules (by killing a faulty program or doing otherwise nasty stuffs) would not loose its conformance because of that. The default behavior of an implementation used under a particular and completely unspecified build-system is irrelevant to the fact that aliasing analysis is allowed across TU boundaries in the model, and the fact that it does not happen in some cases is just an implementation detail - that if not guaranteed by other means can always be changed without even a warning by compiler vendors.
Now that is the situation, in regard with the standard. Should we be happy with it or not is another story.
Standard conformance does. You know, that principle in the name of which the alias-breaking optimizations are done in the first place.
The "as if" principle (there is only one) means that optimized code produces the same results as the abstract semantics (under a certain set of requirements of what it means for the abstract and actual semantics to agree).
The separation between translation phase 7 and 8 is part of that abstract language semantics.
> And compilers are doing it.
GCC currently only does optimizations across translation unit boundaries when it is told via special options, and only for the .o files which are designated as participating in it. This is no different from using __attribute___ or __asm__.