On Mon, Aug 26, 2013 at 7:58 PM, Jason Merrill <ja...@redhat.com> wrote: > On 08/26/2013 11:21 AM, Jan Hubicka wrote: >> >> Our default behaviour special case inline functions that are always >> AVAIL_AVAILABLE and, via decl_replaceable_p, also any COMDAT (that may be >> for >> functions since all COMDATs are also inlines, but makes difference for >> variables I think). > > > Not all COMDAT functions are inlines; template instantiations are also > COMDAT. > > >> My understanding of C++ One Definition Rule, in a strict sense, does not a >> allow in to define two functions of the same name and different semantics >> in a >> valid program. > > > Strictly speaking, the same is true of C: > > "If an identifier declared with external linkage is used in an expression > (other than as part of the operand of a sizeof or _Alignof operator whose > result is an integer constant), somewhere in the entire program there shall > be exactly one external definition for the identifier; otherwise, there > shall be no more than one." > > >> I also think that all DSOs eventually linked together or >> dlopenned are part of the same program. So theoretically, for C++ >> produced >> code, we may go with AVAIL_AVAILABLE everywhere. > > > And for C code as well.
C++'s ODR is much stronger than C's though. For example, C allows definitions for the same inline function to differ -- the out-of-line extern definition does not need to be the same. That is anathema in C++. > > ELF symbol replacement is an extension to C/C++ semantics, which does not > include DSOs; it seems to me that it is up to us to define what assumptions > we want the compiler to be able to make. > > >> On IRC we got into an agreement that we may disallow interposition for >> virtuals, since replacing these seems fishy - they don't even have address >> well >> defined and compiler can freely duplicate and/or unify them. I think same >> apply for C++ constructors and destructors now. > > > But it would be simple to create a DSO which replaces a virtual function or > a constructor, by simply providing a new definition. Since interposition > happens outside the language, I don't think reasoning based on things that > happen within the language makes much sense. > > >> Of course I would be happier with a stronger rule - for instance allowing >> interposition only on plain functions not on methods. > > > Existing uses of interposition apply to plain functions, but that doesn't > mean someone might not want to use it for member functions as well. Agreed. > > I would be happy with an even stronger default that optimizes on the > assumption that no interposition occurs; typically interposition is > overriding a symbol found in a dynamic library (i.e. malloc) rather than a > symbol defined in the same translation unit as the use. > > Jason > Again, strongly agreed. -- Gaby