On Apr 02 2017, Segher Boessenkool wrote:
> Why does powerpc_vsx_ok return true then, ugh.
Because the assembler is new enough. That's all it checks.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for someth
On Sun, Apr 02, 2017 at 03:45:05PM +0200, Andreas Schwab wrote:
> > On Sun, Apr 02, 2017 at 09:26:24AM +0200, Andreas Schwab wrote:
> >> > +/* PR target/79941 */
> >> > +
> >> > +/* { dg-do run } */
> >> > +/* { dg-require-effective-target powerpc_vsx_ok } */
> >> > +/* { dg-options "-mvsx -O2 -sav
On Apr 02 2017, Segher Boessenkool wrote:
> On Sun, Apr 02, 2017 at 09:26:24AM +0200, Andreas Schwab wrote:
>> > +/* PR target/79941 */
>> > +
>> > +/* { dg-do run } */
>> > +/* { dg-require-effective-target powerpc_vsx_ok } */
>> > +/* { dg-options "-mvsx -O2 -save-temps" } */
>>
>> FAIL: gcc.t
On Sun, Apr 02, 2017 at 09:26:24AM +0200, Andreas Schwab wrote:
> > +/* PR target/79941 */
> > +
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target powerpc_vsx_ok } */
> > +/* { dg-options "-mvsx -O2 -save-temps" } */
>
> FAIL: gcc.target/powerpc/fold-vec-mule-misc.c execution test
>
On Sun, Apr 02, 2017 at 09:26:24AM +0200, Andreas Schwab wrote:
> > diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c
> > b/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c
> > new file mode 100644
> > index 000..4bb6185
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.targe
On Mär 09 2017, Will Schmidt wrote:
> diff --git a/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c
> b/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c
> new file mode 100644
> index 000..4bb6185
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c
> @@ -0
Just so there's no duplication of effort -- I'll follow up with a patch to
remove the
outdated built-in.
-- Bill
Bill Schmidt, Ph.D.
GCC for Linux on Power
Linux on Power Toolchain
IBM Linux Technology Center
wschm...@linux.vnet.ibm.com
> On Mar 10, 2017, at 8:24 AM, Bill Schmidt wrote:
>
> J
Jumping in so we can continue the Will/Bill confusion: ;)
The official prototypes from the original AltiVec PIM are:
vector unsigned short vec_mule (vector unsigned char, vector unsigned char);
vector signed short vec_mule (vector signed char, vector signed char);
vector unsigned int vec_mule (v
On Fri, Mar 10, 2017 at 08:08:06AM -0600, Will Schmidt wrote:
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c
> > > @@ -0,0 +1,61 @@
> > > +/* PR target/79941 */
> > > +
> > > +/* { dg-do run } */
> > > +/* { dg-require-effective-target powerpc_vsx_ok } */
> >
On Thu, 2017-03-09 at 17:24 -0600, Segher Boessenkool wrote:
> Hi Will,
>
> On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> > entries were added to the intrinsics-to-be-folded list where the generic
> >
On Thu, Mar 09, 2017 at 07:01:06PM -0500, Michael Meissner wrote:
> > > This looks good to me, but I'll defer the actual review to PowerPC
> > > maintainers. Perhaps there was some hidden reason (xlC compatibility,
> > > whatever) that said that vmuleub etc. should have signed vector arguments
> >
On Thu, Mar 09, 2017 at 05:15:40PM -0600, Segher Boessenkool wrote:
> On Thu, Mar 09, 2017 at 05:59:39PM +0100, Jakub Jelinek wrote:
> > On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> > > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> > > entries were
Hi Will,
On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
On Thu, Mar 09, 2017 at 05:59:39PM +0100, Jakub Jelinek wrote:
> On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> > entries were added to the intrinsics-to-be-folded list where the generic
> > multiplies s
On Tue, Mar 07, 2017 at 03:36:38PM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
> generic
On Thu, Mar 09, 2017 at 10:52:52AM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
> generic
Hi,
Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
entries were added to the intrinsics-to-be-folded list where the generic
multiplies should have been instead. Test coverage in place was for the
generic multiplies, and this was missed by my testing.
The mul[eo]* unsig
On Tue, 2017-03-07 at 22:52 +0100, Jakub Jelinek wrote:
> On Tue, Mar 07, 2017 at 03:36:38PM -0600, Will Schmidt wrote:
> > Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> > entries were added to the intrinsics-to-be-folded list where the generic
> > multiplies should h
On Tue, Mar 07, 2017 at 03:36:38PM -0600, Will Schmidt wrote:
> Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
> entries were added to the intrinsics-to-be-folded list where the generic
> multiplies should have been instead. Test coverage in place was for the
> generic
Hi,
Per PR79941, we are folding the vec_mul{e,o}* operations improperly. Those
entries were added to the intrinsics-to-be-folded list where the generic
multiplies should have been instead. Test coverage in place was for the
generic multiplies, and this was missed by my testing.
Thusly, remove tho
20 matches
Mail list logo
