>>! In D6295#5, @eastig wrote: > You mean that this will hurt performance, don't you?
Yes, there is an (admittedly minor) performance cost to numbering static locals of non-inline functions when no numbering is required. > The code that takes into account declarations in dead code was added in > revision [[ http://llvm.org/viewvc/llvm-project?view=revision&revision=185986 > | 185986 ]] by an engineer from Apple as a fix of the issue > rdar://problem/14204721. I do not have access to Apple's bug tracking system > to see what was the issue. Yep, I'm familiar with the work Eli did here because I helped make the Microsoft ABI version of this work. > The current issue is that different enumeration schemas are used by > getNextDiscriminator. And they produce different names depending on the > function specifier 'inline'. They do. This is by design. Can you elaborate on why this is a problem? The names of static locals in non-inline functions are not ABI-relevant. > According to the C++ standard [dcl.fct.spec]: A static local variable in an > extern inline function always refers to the same object. Note that the standard is explicitly talking about an "extern inline function" here. > This works when everything is compile by one compiler but it does not work > when m_a.cpp is compiled with clang and other files are compiled with g++: Yes, the example you provided is the static local anonymous union case, which I agree needs to be fixed. Can you reupload a new patch which is limited to handling static local anonymous unions in inline functions, and avoid changes to non-ABI relevant names? http://reviews.llvm.org/D6295 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
