A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Details
Diff Detail
Event Timeline
This basically looks good to me, but we really need to get the Itanium ABI to cover this.
lib/CodeGen/CGDecl.cpp | ||
---|---|---|
133–134 | Do you have tests for this change? It seems to imply that dllimport, dllexport, and selectany now work on static local variables and didn't previously. | |
138–140 | Hmm, I wonder why we don't do this for static locals too. Emitting it both eagerly and with a discardable linkage makes very little sense to me... | |
lib/CodeGen/CodeGenModule.cpp | ||
2873–2883 | What should the linkage of the temporary be if the linkage of the variable is strong? Seems we have two choices here:
The difference only seems to matter if it's possible to provide an available_externally definition (that is, for a static data member with an initializer specified within the class). Since our mangling doesn't collide with anyone else's, this will only matter if/when we start emitting the available_externally definitions. |
Give reference temporaries private linkage if their variable has strong, external linkage.
lib/CodeGen/CGDecl.cpp | ||
---|---|---|
133–134 | It is a semantic error for any of those to appear on static local variables. We get this wrong but I believe that's a different bug from this one. | |
lib/CodeGen/CodeGenModule.cpp | ||
2873–2883 | I've updated this differential to implement option #2. This should cause us to use available_externally for the reference temporary if the variable was available_externally while using private if the variable was external. |
Do you have tests for this change? It seems to imply that dllimport, dllexport, and selectany now work on static local variables and didn't previously.