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
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
18 matches
Mail list logo
