Thanks Joseph,

On Mon, Aug 2, 2021 at 12:51 PM Joseph Myers <joseph_at_[hidden]>
wrote:

> ... key questions to consider for C would include VLA issues
> (note that initializers aren't allowed for VLAs at present)


For VLA, it'd be useful to allow = {} in initialization and assignment.

Same-type vla = vla seems straightforward too
(same-size implied by same variably-modified type).

Returning VLA by-value could be implementable in cases
where the caller knows the size of the return array.
In particular if the output is the same size as an input:

// Fixed size array[4] -> array[4] function
float array_function( float (*in)[4] ) [4]
{
    return { f((*in)[0]), f((*in)[1]) ... ) };
}

// Variable size array[n] -> array[n] function
float VLA_function( int n, float (*in)[n] ) [n] // ?
{
    float out[n];
    for (int i = 0; i != n; ++i ) { out[i] = f((*in)[i]); }
    return out;
}

? Is the argument 'n' in scope for the trailing [n] return size ?

True, data-dependent, variable-size return-by-value is another thing.



On Mon, Aug 2, 2021 at 1:55 PM Aaron Ballman via Liaison <
liaison_at_[hidden]> wrote:

> On Mon, Aug 2, 2021 at 12:51 PM Joseph Myers <joseph_at_[hidden]>
> wrote:
> >
> > On Mon, 2 Aug 2021, Aaron Ballman via Liaison wrote:
> >
> > > 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.
> >
> > That's not correct. It's a new type, not mentioned in the existing psABI
> > documents, so it needs to be added to that document, just like other new
> > types.
> >
> > > "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."
> >
> > The above description is a starting point for what goes in psABI
> > documents, but it's not sufficient by itself. For example: are bits
> > beyond the width of the _BitInt value but within the width of the
> smallest
> > basic type containing it required (for argument passing and return, or
> for
> > that matter for objects of the type in memory) to be
> > sign-or-zero-extended, or may they take unspecified values? What about
> > bits between the width of the smallest basic type containing it and the
> > register-sized container? And likewise for the high word of
> > larger-than-register _BitInt values?
> >
> > These are exactly the sort of issues that need to be considered in psABI
> > groups for each architecture. The well-known
> > https://bugs.llvm.org/show_bug.cgi?id=12207 and
> > https://bugs.llvm.org/show_bug.cgi?id=44228 concerning sign and zero
> > extension of narrower-than-register types illustrate the importance of
> > getting such issues specified explicitly in psABI documents.
>
> Thank you for this, Joseph! I've passed along this information to HJ
> to hopefully restart the discussions.
>
> ~Aaron
>
> >
> > --
> > 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/0656.php
>