From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6456 invoked by alias); 25 May 2007 03:57:48 -0000 Received: (qmail 6399 invoked by uid 48); 25 May 2007 03:57:32 -0000 Date: Fri, 25 May 2007 03:57:00 -0000 Message-ID: <20070525035732.6398.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/3187] gcc lays down two copies of constructors In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "maddox at google dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-05/txt/msg02196.txt.bz2 ------- Comment #27 from maddox at google dot com 2007-05-25 04:57 ------- (In reply to comment #20) Ian proposed handling the simple case in which the two constructors ("clones") are identical by emitting the code only once, but labelling it with the symbols for both constructors. This scheme fails in the case that the constructors must go in a comdat group. What do we name the group? If we invent a new name, this will have ABI impact, as other implementations must not step on it. If we use the name of one of the constructors, we may find that the section is discarded in favor of a like-named section produced by another compiler, but which need not define both symbols, resulting in link-incompatibility. It appears, then, that a distinct group name must be used for the combined constructor. As I understand it, this was the principal issue that kept Stuart's patch (referenced in comment #23) from being adopted, so I don't see how this more limited optimization sidesteps the objections to that patch. I spoke with Ian this afternoon, and he agreed with this analysis. It was suggested in the discussion of Stuart's patch that it would be sufficient to provide for a vendor namespace. This seems like a simple, general facility that could be leveraged in multiple contexts, e.g., to support a more general subroutinization optimization. How difficult would it be to get such a provision into the ABI? With a suitably chosen mangling convention, I don't think that name collisions with other ABI-conformant implementations would actually be a problem in practice, so it seems to be more of a matter of agreeing on a convention for the sake of the ABI standard rather than actually managing the transition. Comments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187