Re: [PATCH 4.9][AArch64] Backport 211892: PR/60825 Make float64x1_t in arm_neon.h a proper vector type

[Marcus Shawcroft <marcus dot shawcroft at gmail dot com>]

On 8 July 2014 12:39, Jakub Jelinek <jakub@redhat.com> wrote:
> On Tue, Jul 08, 2014 at 12:28:54PM +0100, Alan Lawrence wrote:
>> This corrects name-mangling of float64x1_t and makes it a distinct type from
>> float64_t, as per ACLE - the error mentioned in the "Caveats" section at
>> https://gcc.gnu.org/gcc-4.9/changes.html.
>>
>> (Only) Changes from the original patch are to remove references to
>> __builtin_aarch64_im_lane_boundsi and the update to the ext_f64_1.c
>> testcase, both of which were introduced in r211058
>> (http://pdtlreviewboard.cambridge.arm.com/r/1339/) which is not being
>> backported. This means that out-of-bounds lane indices will be silently
>> ignored (the implementation just uses lane 0) rather than raising an error
>> message as in mainline.
>
> If any of the changes are ABI changes, then IMHO we shouldn't apply it to
> release branch, better keep 4.9.0 ABI compatible with 4.9.1.
>
>         Jakub

The three patches Alan's change depends on are not ABI changing.
Alan's patch in itself is ABI changing.  This patch breaks mangling,
the following patch which I believe Alan is about to post fixes the
intx1 vectors which causes a change in parameter passing convetion.

 As Alan pointed out in his patch submission, the issue was called out
for 4.9.0 here:

>> float64_t, as per ACLE - the error mentioned in the "Caveats" section at
>> https://gcc.gnu.org/gcc-4.9/changes.html.

... along with a statement that this would be fixed....

Clearly the ABI change between 4.9.0 and 4.9.1 is not ideal, however
the X1 vectors are relatively corner case. Given that this a
relatively new port and we don;t expect many folks to be using this
type in production yet. A number of folk are waiting on 4.9.1 before
they switch to 4.9, some of those folks are likely to be users of the
intrinsics and x1 vectors.  I'd like to see these changes taken now
between 4.9.0 and 4.9.1 rather than take the pain between 4.9.x and
4.10 when we will have a significantly bigger deployed user base.

Cheers
/Marcus