From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57652 invoked by alias); 24 Jan 2017 20:43:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 57127 invoked by uid 89); 24 Jan 2017 20:43:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=sk:dw_at_l, H*f:sk:ory3y12, Adopting, sk:DW_AT_l X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 24 Jan 2017 20:43:47 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 14D3980487 for ; Tue, 24 Jan 2017 20:43:47 +0000 (UTC) Received: from freie.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v0OKheZN001411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 24 Jan 2017 15:43:46 -0500 Received: from livre (livre.home [172.31.160.2]) by freie.home (8.15.2/8.15.2) with ESMTP id v0OKhGtk007601; Tue, 24 Jan 2017 18:43:16 -0200 From: Alexandre Oliva To: Jason Merrill Cc: gcc-patches List Subject: Re: [libcc1] add support for C++ References: <5e2deb89-1870-9615-266e-b7dcb1f43185@redhat.com> Date: Tue, 24 Jan 2017 22:16:00 -0000 In-Reply-To: (Jason Merrill's message of "Tue, 24 Jan 2017 14:46:01 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2017-01/txt/msg01924.txt.bz2 On Jan 24, 2017, Jason Merrill wrote: > On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva wrote: >> On Jan 23, 2017, Jason Merrill wrote: >> >>>>>> + If the newly-created namespace is to be an inline namespace, after >>>>>> + push_namespace, get the nested namespace decl with >>>>>> + get_current_binding_level, pop back to the enclosing namespace, >>>>>> + call using_namespace with INLINE_P, and then push to the inline >>>>>> + namespace again. */ >>>> >>>>> This seems like unnecessary contortions to expect of the caller >>>>> (i.e. GDB). Let's add a new front end function to handle this. >>>> >>>> Heh, it's really nothing compared with some other contortions required >>>> to navigate binding levels, e.g. to reenter a function scope. >>>> >>>> I didn't want to add redundant functionality to the libcc1 API, and we'd >>>> need the ability to separate the introduction or reentry in a namespace, >>>> from a using directive with attribute strong. And since inline >>>> namespaces use the same implementation as that, I figured it made sense >>>> to use the same interface for both. >> >>>> Besides, push_namespace is called a lot more often than using_namespace, >>>> so it makes sense to keep it simpler, and leave the extra parameter for >>>> the less common operation. >>>> >>>> Another argument to keep things as they are is that the inline-ness of a >>>> namespace is not a property related with entering the namespace, but >>>> rather with how names from it are brought into the other namespace. >> >>> Well, it's a property of the namespace. >> >> Even in the case of 'strong' using directives? I didn't think so. > 'strong' using directives should really go away, they were a brief > stop on the way to inline namespaces. We really shouldn't introduce > more functionality based on them. I'll add a deprecated warning > now... Ok, but where does that leave us WRT libcc1? Should we make it impossible for GDB to convey this construct to libcc1 if it finds it in an existing program? (if it is represented in debug information at all) If we make it so, then a new entry point that makes the current namespace inline should fit the bill. Then it would always make it inline to the immediately enclosing namespace. >>>>>> For operator functions, set GCC_CP_FLAG_SPECIAL_FUNCTION in >>>>>> + SYM_KIND, in addition to any other applicable flags, and pass as >>>>>> + NAME a string starting with the two-character mangling for operator >>>>>> + name >>>> >>>>> Perhaps the compiler side should handle this transparently? >>>> >>>> Sorry, I don't understand what you're suggesting. Can you please >>>> elaborate? >> >>> I mean have the compiler recognize that the name is magic and infer >>> that it's a special function. >> >> I'd rather not have accidental namespace collisions: there are several >> layers with different conventions at play, so I decided to mark such >> things explicitly so as to be able to catch misuses. Consider that we >> have GCC's internal identifier representation, mangled identifier >> representation, names exported in debug information, and GDB's internal >> representation. When we get a special name, we want to be sure there >> was not a failure to convert between one's internal representation and >> libcc1's conventions. That's what motivated me to mark them explicitly. > It sounds like you're saying that you want the user to provide the > same information two different ways in order to make sure they're > getting it right. That seems kind of cumbersome. I can't see it that way. The information is not provided in two different ways. Consider, for example, the string used to denote constructors. It's perfectly legitimate to name a member function "C4", but we also use this representation to name constructors, so we need at least an additional bit to tell which space the name belongs to. We could make the encoding part of the string ('_' prefixes, mangling, whatever), but I thought it was better to leave the names unmangled, and use a separate bit flag to "escape" the names into the special functions space. OF course we could have gone with other conventions. One I considered was looking for blanks in the names: they can't appear in regular names, and we could mandate them to be present in special function names. In the end, I went for the separate bit. >> Adopting the name mangling conventions, rather than some enumeration or >> so, is justified by the need for some arbitrary convention, and reusing >> an existing one (that is NOT present in debug information names) > Isn't it present in DW_AT_linkage_name? It's part of the mangled name, yes, but you'd have to look for it. It's not something you'd get to by accident or mistake. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer