On Tue, Aug 27, 2013 at 2:53 PM, Nathan Sidwell <nathan_sidw...@mentor.com> wrote: > On 08/26/13 20:58, Jason Merrill wrote: > >> 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. > > > I had thought that that case (overriding malloc etc) was what this patch was > dealing with. Perhaps I was confused. > > There's nothing particularly special about ctors, dtors and virtual function > implementations. Their common feature, as Jan described, is that it's hard > to take their address: > * ctors don't have names. > * dtors do have names, but you can't take their address. > * virtual function implementations can't have their instance address taken > -- you get the ptr-to-memfn object describing the vtable slot etc. There is > (was?) a GNU extension to work around that, IIRC. > > So that stops a programmer calling these indirectly. However I don't really > see the semantic difference between: > > fptr = &somefunc; ... fptr (...); > and > somefunc (...); > > So treating those 3 types of function specially because you can't use the > former syntax with them seems odd.
Yeah - this is why I'm always worried about "frontend specific" optimizations in the middle-end. If you need to rely stuff that's not visible in GIMPLE then it smells. Richard. > nathan > > -- > Nathan Sidwell
