mangling for fixed point types about cxx-abi HOT 10 CLOSED

Is it expected that the allocation of bits as integer bits and fractional bits would be defined by the target, or should that also be included in the mangling? I'm assuming this is determined by the target.

I don't like either of the suggested approaches. The most obvious available space for a mangling here is encodings beginning with D. So how about:

<builtin-type> ::= [DS] DA <builtin-type> # [_Sat] T _Accum
<builtin-type> ::= [DS] DR <builtin-type> # [_Sat] T _Fract

For example:

signed short _Accum -> DAs
_Sat unsigned long _Accum -> DSDAm
_Sat unsigned short _Fract -> DSDRt

This anticipates DS being permitted in other places, and/or other overflow qualifiers being added eventually; for instance, a _Sat int type is meaningful and might be useful, as might a _Wrap qualifier. If we don't want to plan for that, then DA_ and DR_ would work as encodings for _Sat T _Accum and _Sat T _Fract, respectively.

from cxx-abi.

The integer and fractional bits are determined by the target.

Does the <builtin-type> in the expansion imply that builtin types other than signed/unsigned short/long are allowed to be mangled with _Sat and _Accum/_Fract? We only intend to add the types given above and will not be adding other types like _Sat int _Fract. We throw errors during the Sema stage on finding types like these.

The _Sat qualifier won't also be used with other types and can only be used with _Fract and _Accum, so would the grammar then change to

<builtin-type> ::= DA <builtin-type> # T _Accum
<builtin-type> ::= DR <builtin-type> # T _Fract
<builtin-type> ::= DA_ <builtin-type> # _Sat T _Accum
<builtin-type> ::= DR_ <builtin-type> # _Sat T _Fract

from cxx-abi.

Does the in the expansion imply that builtin types other than signed/unsigned short/long are allowed to be mangled with _Sat and _Accum/_Fract?

It's just a shorthand to avoid needing to explicitly list the six options.

We only intend to add the types given above and will not be adding other types like _Sat int _Fract.

The idea would be that _Sat signed _Fract is mangled as DSDRi (that is, it gets the mangling that would have been used for _Sat int _Fract if such a type existed).

The _Sat qualifier won't also be used with other types and can only be used with _Fract and _Accum

You have no way to know that. An implementation could very reasonably choose to allow it in other places as an extension.

from cxx-abi.

I see, so it's better to have mangle rules that cover different syntactic type combinations even if the type is invalid? (ie. _Sat float _Accum can still have a corresponding mangle even though it is currently an invalid type)

from cxx-abi.

I don't see any particular problem with there being combinations of mangling productions that don't correspond to any valid source program (that's actually really common, eg _Z1fA3_Ri). But I think it'd also be fine to describe the rule as:

<builtin-type> ::= [DS] DA <fixed-point-size> # [_Sat] T _Accum
<builtin-type> ::= [DS] DR <fixed-point-size> # [_Sat] T _Fract
<fixed-point-size> ::= s # short
<fixed-point-size> ::= t # unsigned short
<fixed-point-size> ::= i # plain
<fixed-point-size> ::= j # unsigned
<fixed-point-size> ::= l # long
<fixed-point-size> ::= m # unsigned long

[Note: I moved the DS to the start -- I think that makes more sense, as it's more like a type qualifier in some sense. I've also retroactively made that change to my prior comments.]

But I don't want to get bogged down with how we specify the rule. The thing to focus on right now is what rule we use. Does the one in this comment seem OK to you?

from cxx-abi.

Those rules look fine to me. Thanks! Is there anything else I would need to do to see this in a future ABI?

from cxx-abi.

Could you open a PR for this and make sure it's linked here?

from cxx-abi.

Sorry for the delay. I have #161 ready. I'm not familiar with github PRs though to know how to reference this issue with that PR.

from cxx-abi.

Friendly ping on this. How does this PR look to you?

from cxx-abi.

This was merged in #161

from cxx-abi.