http://llvm.org/bugs/show_bug.cgi?id=10666
Chandler Carruth <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Chandler Carruth <[email protected]> 2011-08-18 04:10:30 CDT --- (In reply to comment #2) > FYI, looking at this with nick, I'm struck by the fact that the problem goes > away if we instantiate Helper outside of a method body. (such as an explicit > instantiation immediately following the definition). > > It seems that some aspect of template instantiation as it happens during > delayed method body parsing is responsible for this malfeasance. This was even more interesting than I originally thought. Here is my further reduced test case: template <int N> struct S { friend void g1(S s) {} void f1() { S<1> s; } friend void g2(S s) {} }; void test(S<1> s1) { g1(s1); g2(s1); } g1's definition is emitted, g2's isn't!!! =D The reason is that we instantiate the template after processing g1's body, but before processing g2's body. As a consequence, when we go to instantiate g1 and g2's declarations as part of instantiating S<1>, we look for function bodies to determine if these function declarations can be subsequently instantiated more fully. While *if* they have bodies this is true, not having a body doesn't necessarily mean it isn't true. There already was a comment indicating it might be useful to preserve this subsequent instantiation regardless of whether a body is attached, and doing so avoids this entire problem. Testing doesn't reveal any ill effects when a body is *not* in fact involved, so all seems well. I've committed this fix (with accompanying tests) in r137934. If an alternative implementation would be preferred, please chime in on the review and I'll be happy to change it up. -- Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
