This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [libcc1] add support for C++


On Tue, Jan 24, 2017 at 3:43 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Jan 24, 2017, Jason Merrill <jason@redhat.com> wrote:
>> On Mon, Jan 23, 2017 at 7:21 PM, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> On Jan 23, 2017, Jason Merrill <jason@redhat.com> 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)

It isn't represented in the debug information.

> 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.

Sounds reasonable.

>>>>>> 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.

All right.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]