On Wed, May 28, 2014 at 4:00 PM, Duncan P. N. Exon Smith < [email protected]> wrote:
> > > On 2014-May-28, at 15:48, Reid Kleckner <[email protected]> wrote: > > Emitting all inline functions seems like it will require semantic > changes and it's overkill. The specific case I'm thinking of is: > > #include <memory> > > struct Bar; > > struct Foo { > > Foo(Bar *b) : p(b) {} > > std::unique_ptr<Bar> p; > > }; > > > > We need to require a complete type for Bar if we want to emit ~Foo, > because ~unique_ptr<Bar> deletes Bar, but we don't require that currently. > > Hmm... nice catch. This would not be a good thing. A more accurate reduction: template <typename T> struct my_unique_ptr { my_unique_ptr(T *p) : p(p) {} ~my_unique_ptr() { delete p; } T *p; }; struct Bar; struct Foo { Foo(); my_unique_ptr<Bar> p; }; My original constructor would have instantiated ~unique_ptr<Bar> from the inline ctor. > > I don't know the details of coverage, but is there another way to > represent "I saw this inline function, but nobody called it"? My straw man > suggestion is to emit a single counter for the entry block that will either > always be zero or be comdat merged with another TU that uses the inline > function. > > That's an interesting idea, but when inline functions are used, the > counters > are declared `linkonce_odr` so that they'll coallesce between TUs. This > sounds like it would violate the ODR. Something similar might work though. > Hmm. They should actually be weak_odr if you don't want them to be discarded. IMO this is better than @llvm.used, which has pretty weird semantics. I don't know enough about what goes into the counters to figure out the odr issue.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
