https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65892
--- Comment #49 from Andrew Haley <aph at gcc dot gnu.org> --- (In reply to James Kuyper Jr. from comment #46) > (In reply to Andrew Haley from comment #42) > ... > > In order to use type-based alias analysis in any LTO framework it's > > necessary to save type information, and this is just more type > > information. ... > > > ... The question is, I suppose, how to handle the scopes of > > union declarations. I'd just treat them as being global, which in > > practice isn't unrealistic because such declarations are in header > > files in global scope and shared anyway. > > Why not use the actual scope of the completed union declaration, > which is what the relevant rule refers to? The principle of type-based alias analysis is that all you know about two types is their types, not the location of any code that uses them. There are no scopes. The oracle, given only the types, has to say whether they alias or not, regardless of where those types are used in a program. The location isn't an input to the oracle. Bear in mind that inlining and other kinds of code motion happen, and code is often evaluated "outside" the scopes in which it was written and in a completely different order. That's all perfectly normal optimization. Besides, when the alias oracle is consulted, all that scope stuff has gone. It's only relevant to the front end. > > So, if any union types with a common initial sequence are declared > > anywhere in a program, then their member types alias. > > As I understand it, the visibility rule was added specifically for > the purpose of NOT requiring that the entire program be covered by > this exception. I don't think so. As I read it, it was a way of declaring to the compiler that they types are intended to alias. > Knowledgeable people writing code intended to take advantage of this > feature of C are likely to carefully place completed declarations of > the union's type so they disable those optimizations only where they > need to be disabled, and to minimize the amount of code where this > exception would unnecessarily disable useful optimizations. Perhaps so, yes, but in practice it'd be pretty hard to do that. Functions can only be defined in the other scope, and there's no way to undefine a union type. I guess you could be clever and put all of the functions which needed to know about the aliasing at the end of a translation unit.
