Date: Mon, 2 Aug 2021 12:22:29 -0400
On Mon, Aug 2, 2021 at 12:14 PM Joseph Myers via Liaison
<liaison_at_[hidden]> wrote:
>
> On Sun, 1 Aug 2021, will wray via Liaison wrote:
>
> > int f()[2] // *#0*
>
> That needs ABI changes in architecture-specific psABI documents to
> describe how arrays are returned by value. It might help if the proposers
> (a) had general proposals for what those ABI changes would look like and
> (b) expressed the intention to make those proposals to the corresponding
> ABI working groups for various architectures if the language proposal is
> accepted.
>
> (Cf. _BitInt, where the proposers did (a) and expressed the intention in
> (b). I don't know if (b) has yet been followed through on there for any
> architectures, however; I haven't yet seen such proposals on the x86-64 or
> ia32 groups at least.)
Regarding _BitInt:
I spoke with Lu Hongjiu (Intel's rep on psABI matters) internally
about psABI changes and his determination was that no psABI changes
were needed to support _BitInt because they aligned with existing
calling conventions.
"With _BitInt(N) types align with existing calling conventions. They
have the same size and alignment as the smallest basic type that can
contain them. Types that are larger than __int64_t are conceptually
treated as struct of register size chunks. The number of chunks is the
smallest number that can contain the type. there is no need for psABI
change."
I filed an Itanium ABI issue to kick off discussions there, but it's
not attracted much attention thus far:
https://github.com/itanium-cxx-abi/cxx-abi/issues/128
~Aaron
>
> I would suggest that key questions to consider for C would include VLA
> issues (note that initializers aren't allowed for VLAs at present), as
> well as how to avoid incompatibilities if you change the existing rule
> that decay of functions and arrays to pointers occurs very early in almost
> all contexts.
>
> --
> Joseph S. Myers
> joseph_at_[hidden]
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/08/0653.php
<liaison_at_[hidden]> wrote:
>
> On Sun, 1 Aug 2021, will wray via Liaison wrote:
>
> > int f()[2] // *#0*
>
> That needs ABI changes in architecture-specific psABI documents to
> describe how arrays are returned by value. It might help if the proposers
> (a) had general proposals for what those ABI changes would look like and
> (b) expressed the intention to make those proposals to the corresponding
> ABI working groups for various architectures if the language proposal is
> accepted.
>
> (Cf. _BitInt, where the proposers did (a) and expressed the intention in
> (b). I don't know if (b) has yet been followed through on there for any
> architectures, however; I haven't yet seen such proposals on the x86-64 or
> ia32 groups at least.)
Regarding _BitInt:
I spoke with Lu Hongjiu (Intel's rep on psABI matters) internally
about psABI changes and his determination was that no psABI changes
were needed to support _BitInt because they aligned with existing
calling conventions.
"With _BitInt(N) types align with existing calling conventions. They
have the same size and alignment as the smallest basic type that can
contain them. Types that are larger than __int64_t are conceptually
treated as struct of register size chunks. The number of chunks is the
smallest number that can contain the type. there is no need for psABI
change."
I filed an Itanium ABI issue to kick off discussions there, but it's
not attracted much attention thus far:
https://github.com/itanium-cxx-abi/cxx-abi/issues/128
~Aaron
>
> I would suggest that key questions to consider for C would include VLA
> issues (note that initializers aren't allowed for VLAs at present), as
> well as how to avoid incompatibilities if you change the existing rule
> that decay of functions and arrays to pointers occurs very early in almost
> all contexts.
>
> --
> Joseph S. Myers
> joseph_at_[hidden]
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2021/08/0653.php
Received on 2021-08-02 11:22:45