mcgrathr added a comment. In https://reviews.llvm.org/D53787#1279899, @rsmith wrote:
> Replacing the global new and delete is supposed to be a whole-program > operation (you only get one global allocator). Otherwise you couldn't > allocate memory in one DSO and deallocate it in another. (And nor could > inline functions etc.) > > If you really want to do this weird thing, and you understand what you're > getting yourself into, I don't see a problem with having a dedicated flag for > it, but don't break all existing users of -fvisibility=. I don't really understand how these functions are different from other functions. The language standards don't have anything to say about ELF visibility. What you say about "whole-program operation" is true of any global symbol. When we use visibility switches or annotations it's because we want to change how global symbols behave. I don't understand the rationale for treating these particular functions differently from all other functions. It is especially bizarre to me that explicit attributes on the definition sites are silently ignored for these functions and no others. Few if any existing users of -fvisibility or visibility attributes use them on definitions of operator new and operator delete. The notion that existing users are expecting this bizarrely inconsistent behavior seems pretty questionable to me. But indeed I do know what I'm doing and I am willing to tell the compiler even more explicitly if you insist that I should have to do that for some reason. I don't care what the switch is called. This is only ever going to be used in basically one place in the world (the libc++ definitions when building it for hermetic static linking). Repository: rC Clang https://reviews.llvm.org/D53787 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
