[PATCH,rs6000] Fix vec_permxor builtin support, fix test cases for vec_permxor and vec_insert4b

[Bill Schmidt]

> On Jun 5, 2018, at 5:04 PM, Carl Love <cel@us.ibm.com> wrote:
> 
> On Tue, 2018-06-05 at 16:45 -0500, Bill Schmidt wrote:
>> Hi Carl,
>> 
>> That looks like a typo in the ABI document to me.  The return type
>> should match the
>> argument types like it does for the other variants.  Sorry -- I'll
>> open a bug against
>> the ABI doc.
> 
> So, the ABI doc currently says:
> 
>    vector unsigned char vec_permxor (vector signed char, vector signed char, vector signed char);
>    vector unsigned char vec_permxor (vector unsigned char, vector unsigned char, vector unsigned char);
> 
> and we want it to read:
> 
>    vector signed char vec_permxor (vector signed char, vector signed char, vector signed char);
>    vector unsigned char vec_permxor (vector unsigned char, vector unsigned char, vector unsigned char);

Yep, correct!
Bill
> 
> If so, we only want the changes to vec_insert4b in builtins-7-p9-runnable.c.
> 
> I will re-spin the patch.  Thanks.
> 
>                  Carl Love
> 
>> vec_insert4b
>> Thanks!  Good catch, Segher.
>> 
>> -- Bill
>> 
>> Bill Schmidt, Ph.D.
>> STSM, GCC Architect for Linux on Power
>> IBM Linux Technology Center
>> wschmidt@linux.vnet.ibm.com
>> 
>>> On Jun 5, 2018, at 4:32 PM, Segher Boessenkool <segher@kernel.crash
>>> ing.org> wrote:
>>> 
>>> Hi Carl,
>>> 
>>> On Tue, Jun 05, 2018 at 01:57:52PM -0700, Carl Love wrote:
>>>> The following patch fixes the return type for the existing
>>>> vec_permxor
>>>> builtin to match the ABI specification.  The test case for the
>>>> builtin
>>>> is also updates.
>>> 
>>> Hrm, is that a bug in the ABI doc though?  Bill?  Most older
>>> builtins
>>> return their source type; some newer ones always return
>>> unsigned?  Is this
>>> on purpose?
>>> 
>>>> Secondly, the first argument of the vec_insert4b() builtin test
>>>> case is
>>>> fixed to match the ABI specification for the builtin.
>>> 
>>> The patch is fine for trunk if the ABI doc is correct.  Thanks,
>>> 
>>> 
>>> Segher
>>> 
>> 
>>