[cxx-abi-dev] Mangling "transaction-safe function"

[Jason Merrill]

On 09/29/2015 11:27 PM, Jason Merrill wrote:
> On 09/29/2015 08:34 PM, Richard Smith wrote:
>> On 29 September 2015 at 11:09, Jason Merrill <jason at redhat.com> wrote:
>>
>>> The Transactional Memory TS introduces "transaction-safe function"
>>> types,
>>> which are distinct from non-transaction-safe function types, though the
>>> former converts to the latter.  So we need to represent this in
>>> mangling.
>>>
>>> I think no change to mangling of actual functions is necessary, since
>>> functions that differ only in their tx-qualifier cannot be overloaded.
>>
>> I thought the intent was that we'd emit two function bodies for a
>> transaction-safe function definition (one for the case where we are
>> inside
>> an atomic block, another for the case where we are not). Do we also
>> need a
>> new function mangling for the former case?
>
> Yes, I thought I had mentioned that in a follow-up, but evidently not.
> GCC currently mangles the transaction entry point as
>
> <special_name> ::= GTt <encoding>
>
>>> So we only need to worry about function types.
>>>
>>> One possibility for handling it would be to add a qualifier 'T' after
>>> the
>>> <ref-qualifier> at the end of <function-type>, but that complicates the
>>> ambiguity between these qualifiers and parameter types.
>>>
>>> I think my preference is to make it a normal type qualifier, perhaps
>>> using "Dx", so void (*)() transaction_safe becomes "PDxFvvE".

There's also the question of whether the non-transaction-safe function 
type is substitutable in this mangling.  I think we might as well allow 
it, as we do for cv-qualified types.

>>>
>>> We also need to add a __transaction_safe_mask to
>>> __pbase_type_info::__masks so that exception handlers can perform the
>>> transaction safety conversion.
>>
>> Would you also use the same __function_type_info for the pointee type in
>> typeid(void (*)() transaction_safe) and typeid(void(*)())? That seems
>> like
>> an odd fit for the language semantics ("transaction_safe" is part of the
>> function type, not a layer on top of it like cv-qualifiers are), but
>> necessary if we want the exception handler to be able to efficiently
>> check
>> for a match.
>
> Right.  This seemed simpler to me than adding a new
> __tx_safe_function_type_info class.
>
> Jason
>