[PATCH, rs6000] Fix instruction counts on powerpc64 test cases. (take 2)

2019-02-05 Thread Bill Seurer
[PATCH, rs6000] Fix instruction counts on powerpc64 test cases.

This patch fixes the assembler instruction counts for some test cases
that started failing due to changes in code generation.  The targets
were adjusted a bit as well to avoid generating BE/LE endian code on
unsupported platforms.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu (power 8 and
power 9) and powerpc64be-unknown-linux-gnu (power 7 and power 8) with
no regressions.  Is this ok for trunk?


2019-02-04  Bill Seurer  

* gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c: Update 
instruction counts and target.
* gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c: Update 
instruction counts and target.
* gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p9.c: Update 
instruction counts and target.

Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c  (revision 268524)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c  (working copy)
@@ -1,28 +1,20 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-do compile { target { lp64 && be } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-mvsx -O2 -mcpu=power7 -dp" } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power7" } } */
 
-
 /* Expected instruction counts for Power 7 */
 
 /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
 /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
-/* { dg-final { scan-assembler-times "xxlnor" 8 { target le } } } */
-/* { dg-final { scan-assembler-times "xxlnor" 7 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp" 5 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp" 6 { target be }} } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp." 5 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp." 6 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp" 9 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp" 8 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp." 9 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp." 8 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp" 6 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp" 7 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp." 6 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp." 7 { target be } } } */
+/* { dg-final { scan-assembler-times "xxlnor" 5 } } */
+/* { dg-final { scan-assembler-times {\mxvcmpeqdp\s} 1 } } */
+/* { dg-final { scan-assembler-times {\mxvcmpeqdp\.\s} 5 } } */
+/* { dg-final { scan-assembler-times {\mxvcmpgtdp\s} 2 } } */
+/* { dg-final { scan-assembler-times {\mxvcmpgtdp\.\s} 5 } } */
+/* { dg-final { scan-assembler-times {\mxvcmpgedp\s} 1 } } */
+/* { dg-final { scan-assembler-times {\mxvcmpgedp\.\s} 6 } } */
 /* { dg-final { scan-assembler-times "xvrdpim" 1 } } */
 /* { dg-final { scan-assembler-times "xvmaddadp" 1 } } */
 /* { dg-final { scan-assembler-times "xvmsubadp" 1 } } */
Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c  (revision 268524)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c  (working copy)
@@ -1,16 +1,15 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-do compile { target { lp64 } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-mvsx -O2 -mcpu=power8" } */
 /* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
 
-
 /* Expected instruction counts for Power 8.  */
 
 /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
 /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
-/* { dg-final { scan-assembler-times "xxlnor" 8 { target le } } } */
-/* { dg-final { scan-assembler-times "xxlnor" 7 { target be } } } */
+/* { dg-final { scan-assembler-times "xxlnor" 6 { target le } } } */
+/* { dg-final { scan-assembler-times "xxlnor" 5 { target be } } } */
 
 /* We generate xxlor instructions for many reasons other than or'ing vector
operands or calling __builtin_vec_or(), which  means we cannot rely on
@@ -18,16 +17,16 @@
xxlor instruction was generated.  */
 /* { dg-final { scan-

Re: [PATCH, rs6000] Fix instruction counts on powerpc64 test cases.

2019-02-05 Thread Bill Seurer

On 02/05/19 05:31, Segher Boessenkool wrote:

Do we not want to test this on LE anymore?  Oh, P7, heh.  Okay.  Not
enough coffee yet :-)


It will work if I specify -mbig-endian -mabi=elfv1 but yeah, we don't 
really care about P7 generating LE code.



+/* { dg-final { scan-assembler-times "xvcmpgedp" 6 } } */
+/* { dg-final { scan-assembler-times "xvcmpgedp." 6 } } */

These need fixing still: both of these match
   xvcmpgedp 0,1,2
because dot means "any character", in a regexp.  Maybe

/* { dg-final { scan-assembler-times {\mxvcmpgedp\s} 6 } } */
/* { dg-final { scan-assembler-times {\mxvcmpgedp\.\s} 6 } } */

(and with the counts fixed).  (Same for all other dot insns of course).



A lot of these test cases (as in power-specific opcode tests) test for 
both OPCODE and OPCODE. which as you noted matches both.  Many others 
just test for OPCODE (which will also match OPCODE.).  I meant to ask if 
that was actually useful as they always matched the same thing either way.


I will do the updates you recommended.  Should I post the updated diffs 
or is this enough to submit the patch?

--

-Bill Seurer



[PATCH, rs6000] Fix instruction counts on powerpc64 test cases.

2019-02-04 Thread Bill Seurer

[PATCH, rs6000] Fix instruction counts on powerpc64 test cases.

This patch fixes the assembler instruction counts for some test cases
that started failing due to changes in code generation.  The targets
were adjusted a bit as well to avoid generating BE/LE endian code on
unsupported platforms.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu (power 8 and
power 9) and powerpc64be-unknown-linux-gnu (power 7 and power 8) with
no regressions.  Is this ok for trunk?


2019-02-04  Bill Seurer  

* gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c: Update
instruction counts and target.
* gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c: Update
instruction counts.
* gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p9.c: Update
instruction counts and target.

Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c  (revision 268524)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p7.c  (working copy)
@@ -1,28 +1,21 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-do compile { target { powerpc64-*-* && lp64 } } } */
+/* Note: powerpc64-*-* is BE only. */
 /* { dg-skip-if "" { powerpc*-*-darwin* } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-mvsx -O2 -mcpu=power7 -dp" } */
-/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } 
{ "-mcpu=power7" } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc64-*-* } { "-mcpu=*" } 
{ "-mcpu=power7" } } */


-
 /* Expected instruction counts for Power 7 */

 /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
 /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
-/* { dg-final { scan-assembler-times "xxlnor" 8 { target le } } } */
-/* { dg-final { scan-assembler-times "xxlnor" 7 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp" 5 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp" 6 { target be }} } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp." 5 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpeqdp." 6 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp" 9 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp" 8 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp." 9 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpgtdp." 8 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp" 6 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp" 7 { target be } } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp." 6 { target le } } } */
-/* { dg-final { scan-assembler-times "xvcmpgedp." 7 { target be } } } */
+/* { dg-final { scan-assembler-times "xxlnor" 5 } } */
+/* { dg-final { scan-assembler-times "xvcmpeqdp" 6 } } */
+/* { dg-final { scan-assembler-times "xvcmpeqdp." 6 } } */
+/* { dg-final { scan-assembler-times "xvcmpgtdp" 7 } } */
+/* { dg-final { scan-assembler-times "xvcmpgtdp." 7 } } */
+/* { dg-final { scan-assembler-times "xvcmpgedp" 7 } } */
+/* { dg-final { scan-assembler-times "xvcmpgedp." 7 } } */
 /* { dg-final { scan-assembler-times "xvrdpim" 1 } } */
 /* { dg-final { scan-assembler-times "xvmaddadp" 1 } } */
 /* { dg-final { scan-assembler-times "xvmsubadp" 1 } } */
Index: gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c
===
--- gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c  (revision 268524)
+++ gcc/testsuite/gcc.target/powerpc/vsx-vector-6.p8.c  (working copy)
@@ -1,16 +1,15 @@
-/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-do compile { target { powerpc64*-*-* && lp64 } } } */
 /* { dg-skip-if "" { powerpc*-*-darwin* } } */
 /* { dg-require-effective-target powerpc_vsx_ok } */
 /* { dg-options "-mvsx -O2 -mcpu=power8" } */
-/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } 
{ "-mcpu=power8" } } */
+/* { dg-skip-if "do not override -mcpu" { powerpc64*-*-* } { "-mcpu=*" 
} { "-mcpu=power8" } } */


-
 /* Expected instruction counts for Power 8.  */

 /* { dg-final { scan-assembler-times "xvabsdp" 1 } } */
 /* { dg-final { scan-assembler-times "xvadddp" 1 } } */
-/* { dg-final { scan-assembler-times "xxlnor" 8 { target le } } } */
-/* { dg-final { scan-assembler-times "xxlnor" 7 { target be } } } */
+/* { dg-final { scan-assembler-times "x

[PATCH, rs6000] Disable ASLR in sanitizer on powerpc64.

2018-11-08 Thread Bill Seurer
[PATCH, rs6000] Disable ASLR in sanitizer on powerpc64.

Cherry pick powerpc64 sanitizer fix from upstream llvm.

See https://reviews.llvm.org/rL346030 and
https://reviews.llvm.org/D52900.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu with no regressions.  Is this ok for trunk?


2018-11-08  Bill Seurer  

* libsanitizer/sanitizer_common/sanitizer_linux.cc (CheckASLR):
Disable ASLR for powerpc64 when using sanitizers.

Index: libsanitizer/sanitizer_common/sanitizer_linux.cc
===
--- libsanitizer/sanitizer_common/sanitizer_linux.cc(revision 265876)
+++ libsanitizer/sanitizer_common/sanitizer_linux.cc(working copy)
@@ -2008,6 +2008,17 @@
 Printf("This sanitizer is not compatible with enabled ASLR\n");
 Die();
   }
+#elif SANITIZER_PPC64V2
+  // Disable ASLR for Linux PPC64LE.
+  int old_personality = personality(0x);
+  if (old_personality != -1 && (old_personality & ADDR_NO_RANDOMIZE) == 0) {
+VReport(1, "WARNING: Program is being run with address space layout "
+   "randomization (ASLR) enabled which prevents the thread and "
+   "memory sanitizers from working on powerpc64le.\n"
+   "ASLR will be disabled and the program re-executed.\n");
+CHECK_NE(personality(old_personality | ADDR_NO_RANDOMIZE), -1);
+ReExec();
+  }
 #else
   // Do nothing
 #endif
-- 

-Bill Seurer



Re: [PATCH 0/7] libsanitizer: merge from trunk

2018-10-29 Thread Bill Seurer

On 10/29/18 10:26, Michael Matz wrote:

Hi,

On Mon, 29 Oct 2018, Bill Seurer wrote:


Just for the record: am I right that any system using 44 bit of VMA will
fail because
anything + (1 << 44) will be out of process address space?


Yes.


And I noticed that documentation in sanitizer_linux.cc is misleading:

...
uptr GetMaxVirtualAddress() {
#if (SANITIZER_NETBSD || SANITIZER_OPENBSD) && defined(__x86_64__)
return 0x7f7ff000ULL;  // (0x7f80 - PAGE_SIZE)
#elif SANITIZER_WORDSIZE == 64
# if defined(__powerpc64__) || defined(__aarch64__)
// On PowerPC64 we have two different address space layouts: 44- and
46-bit.
// We somehow need to figure out which one we are using now and choose
// one of 0x0fffUL and 0x3fffUL.
...

That should be adjusted.


Apparently for ppc64 there are many different layouts now, 44, 46, 47, 49,
52
at least depending on which kernel and page size you choose.
So, ideally we want some choice that works with all of them.  Shadow offset
1ULL<<44 is not that choice.


We (llvm team) tried to get it to work on all the different kernels but didn't
find anything that worked.  Finally we just went with a value that worked on
the newer kernels as the 44 bit one was not a target of concern.


I'm still wondering what didn't work with 41 bits?  AFAICS, due to
highshadow=highmem-offset and lowshadow=low+offset, and the existence of a
non-empty shadow-gap, offset must be minimum(vbits)-3 (vbits being one of
the above numbers).  Why would 41 not work for the other vbit setting?
It would lead to a large shadow gap, but so?  If a shadow-gap isn't
necessary then minimum(vbits)-2 would also work.


41 was what the value previously was and it did not work (IIRC with 47 
bit VMA kernels which were "new" at the time) thus the change.


If someone comes up with something that they think will work I am 
willing to test it with both llvm and gcc.

--

-Bill Seurer



Re: [PATCH 0/7] libsanitizer: merge from trunk

2018-10-29 Thread Bill Seurer

On 10/29/18 06:24, Jakub Jelinek wrote:

On Mon, Oct 29, 2018 at 12:13:04PM +0100, Martin Liška wrote:

Just for the record: am I right that any system using 44 bit of VMA will fail 
because
anything + (1 << 44) will be out of process address space?


Yes.


And I noticed that documentation in sanitizer_linux.cc is misleading:

...
uptr GetMaxVirtualAddress() {
#if (SANITIZER_NETBSD || SANITIZER_OPENBSD) && defined(__x86_64__)
   return 0x7f7ff000ULL;  // (0x7f80 - PAGE_SIZE)
#elif SANITIZER_WORDSIZE == 64
# if defined(__powerpc64__) || defined(__aarch64__)
   // On PowerPC64 we have two different address space layouts: 44- and 46-bit.
   // We somehow need to figure out which one we are using now and choose
   // one of 0x0fffUL and 0x3fffUL.
...

That should be adjusted.


Apparently for ppc64 there are many different layouts now, 44, 46, 47, 49, 52
at least depending on which kernel and page size you choose.
So, ideally we want some choice that works with all of them.  Shadow offset
1ULL<<44 is not that choice.


We (llvm team) tried to get it to work on all the different kernels but 
didn't find anything that worked.  Finally we just went with a value 
that worked on the newer kernels as the 44 bit one was not a target of 
concern.


--

-Bill Seurer



Re: [PATCH 0/7] libsanitizer: merge from trunk

2018-10-26 Thread Bill Seurer

On 10/26/18 03:57, Jakub Jelinek wrote:

On Thu, Oct 25, 2018 at 12:49:42PM +0200, Jakub Jelinek wrote:

On Thu, Oct 25, 2018 at 12:15:46PM +0200, marxin wrote:

I've just finished my first merge from libsanitizer mainline. Overall it
looks fine, apparently ABI hasn't changed and so that SONAME bump is not
needed.


Given the 6/7 patch, I think you need to bump libasan soname (it would be
weird to bump it on powerpc64* only).


BTW, how can shadow offset be 1UL<<44 on powerpc64?  That seems like they
don't want to support anything but very recent kernels.
E.g. looking at Linux 3.4 arch/powerpc/include/asm/processor.h
I see
/* 64-bit user address space is 44-bits (16TB user VM) */
#define TASK_SIZE_USER64 (0x1000UL)
so, the new choice must be incompatible with lots of kernels out there.
Move recent kernels have:
#define TASK_SIZE_64TB  (0x4000UL)
#define TASK_SIZE_128TB (0x8000UL)
#define TASK_SIZE_512TB (0x0002UL)
#define TASK_SIZE_1PB   (0x0004UL)
#define TASK_SIZE_2PB   (0x0008UL)
#define TASK_SIZE_4PB   (0x0010UL)
but 4.15 still tops at 512TB, 4.10 has just 64TB as the only choice, 3.8 as
well.

CCing Bill as he made this change.

Jakub



At the time for llvm the concern was to get it to work on newer kernels 
and not worry (much) about the older ones.  I did spend some time trying 
to get it to work for both.


--

-Bill Seurer



[PATCH, rs6000] Fix expected error output for test case.

2018-10-03 Thread Bill Seurer
[PATCH, rs6000] Fix expected error output for test case.

r264355 removed some spelling suggestions including for "bool" as used
in this test case.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64be-unknown-linux-gnu with no regressions.  Is this ok for trunk?

2018-10-03  Bill Seurer  

PR target/87486
* gcc.target/powerpc/undef-bool-2.c: Fix expected error output.

Index: gcc/testsuite/gcc.target/powerpc/undef-bool-2.c
===
--- gcc/testsuite/gcc.target/powerpc/undef-bool-2.c (revision 264812)
+++ gcc/testsuite/gcc.target/powerpc/undef-bool-2.c (working copy)
@@ -9,7 +9,7 @@
 
 #include 
 
-bool foo (int x) /* { dg-error "unknown type name 'bool'; did you mean 
'_Bool'?" } */
+bool foo (int x) /* { dg-error "unknown type name 'bool'" } */
 {
   return x == 2;
 }

-- 

-Bill Seurer



[PATCH, rs6000] Fix address sanitizer for powerpc64.

2018-04-17 Thread Bill Seurer
[PATCH, rs6000] Fix address sanitizer for powerpc64.

This patch fixes problems that asan has on powerpc64 running on some old
kernels and also very new kernels.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85394 and
https://github.com/google/sanitizers/issues/933 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64be-unknown-linux-gnu with no regressions.  Is this ok for trunk?


2018-04-17  Bill Seurer  <seu...@linux.vnet.ibm.com>

PR sanitizer/85389
* asan/asan_allocator.h: Switch to use dynamic base for the allocator
region.

Index: libsanitizer/asan/asan_allocator.h
===
--- libsanitizer/asan/asan_allocator.h  (revision 259447)
+++ libsanitizer/asan/asan_allocator.h  (working copy)
@@ -122,7 +122,7 @@ const uptr kAllocatorSpace = ~(uptr)0;
 const uptr kAllocatorSize  =  0x400ULL;  // 4T.
 typedef DefaultSizeClassMap SizeClassMap;
 # elif defined(__powerpc64__)
-const uptr kAllocatorSpace =  0xa00ULL;
+const uptr kAllocatorSpace = ~(uptr)0;
 const uptr kAllocatorSize  =  0x200ULL;  // 2T.
 typedef DefaultSizeClassMap SizeClassMap;
 # elif defined(__aarch64__) && SANITIZER_ANDROID

-- 

-Bill Seurer



Re: [PATCH, rs6000] pr58684, pr83759 Disable test cases that fail on powerpc64.

2018-01-12 Thread Bill Seurer

On 01/12/2018 11:23 AM, Segher Boessenkool wrote:

On Thu, Jan 11, 2018 at 01:36:53PM -0600, Bill Seurer wrote:

[PATCH, rs6000] pr58684, pr83759 Disable test cases that fail on powerpc64.

This patch disables a few test cases on powerpc64 that fail after r256380
due to a longstanding issue with floating-point compares.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64be-unknown-linux-gnu with no regressions.  Is this ok for trunk?


2018-01-11  Bill Seurer  <seu...@linux.vnet.ibm.com>

PR sanitizer/65479
* gcc/testsuite/gcc.dg/torture/inf-compare-1.c: Add dg-skip.
* gcc/testsuite/gcc.dg/torture/inf-compare-2.c: Add dg-skip.
* gcc/testsuite/gcc.dg/torture/inf-compare-3.c: Add dg-skip.
* gcc/testsuite/gcc.dg/torture/inf-compare-4.c: Add dg-skip.


Could you xfail them instead?  So that we automatically know what to
update when the problem finally is fixed.  Or will that not work for
some reason?


I actually originally did xfail on the dg-if but then got XPASSes on the 
compilation steps.  I think this will work:


/* { dg-do run { xfail { powerpc*-*-* } } } */
/* remove the xfail for powerpc when pr58684 is fixed */
/* { dg-add-options ieee } */
/* { dg-require-effective-target fenv_exceptions } */

--

-Bill Seurer



Re: [PATCH, rs6000] pr58684, pr83759 Disable test cases that fail on powerpc64.

2018-01-11 Thread Bill Seurer

On 01/11/2018 02:20 PM, Joseph Myers wrote:

On Thu, 11 Jan 2018, Bill Seurer wrote:


PR sanitizer/65479


Wrong bug number.


+/* { dg-skip-if "remove this when pr58684 is fixed" { powerpc64*-*-* } } */


As previously noted, testing powerpc64 like that in tests is always wrong
(because you can have 64-bit multilibs with a compiler defaulting to
32-bit, and vice versa, so need to test powerpc*-*-* together with
relevant effective-targets for the multilib under test being 32-bit or
64-bit).

In the present case, there is nothing specific to 64-bit at all; this bug
applies to hard-float powerpc for both 32-bit and 64-bit, so just testing
powerpc*-*-* without any effective-target is appropriate (I don't think
it's worth trying to exclude soft-float from what's covered).



Thanks, I will fix those.

--

-Bill Seurer



[PATCH, rs6000] pr58684, pr83759 Disable test cases that fail on powerpc64.

2018-01-11 Thread Bill Seurer
[PATCH, rs6000] pr58684, pr83759 Disable test cases that fail on powerpc64.

This patch disables a few test cases on powerpc64 that fail after r256380
due to a longstanding issue with floating-point compares.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64be-unknown-linux-gnu with no regressions.  Is this ok for trunk?


2018-01-11  Bill Seurer  <seu...@linux.vnet.ibm.com>

PR sanitizer/65479
* gcc/testsuite/gcc.dg/torture/inf-compare-1.c: Add dg-skip.
* gcc/testsuite/gcc.dg/torture/inf-compare-2.c: Add dg-skip.
* gcc/testsuite/gcc.dg/torture/inf-compare-3.c: Add dg-skip.
* gcc/testsuite/gcc.dg/torture/inf-compare-4.c: Add dg-skip.

Index: gcc/testsuite/gcc.dg/torture/inf-compare-1.c
===
--- gcc/testsuite/gcc.dg/torture/inf-compare-1.c(revision 256541)
+++ gcc/testsuite/gcc.dg/torture/inf-compare-1.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-add-options ieee } */
 /* { dg-require-effective-target fenv_exceptions } */
+/* { dg-skip-if "remove this when pr58684 is fixed" { powerpc64*-*-* } } */
 
 #include 
 
Index: gcc/testsuite/gcc.dg/torture/inf-compare-2.c
===
--- gcc/testsuite/gcc.dg/torture/inf-compare-2.c(revision 256541)
+++ gcc/testsuite/gcc.dg/torture/inf-compare-2.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-add-options ieee } */
 /* { dg-require-effective-target fenv_exceptions } */
+/* { dg-skip-if "remove this when pr58684 is fixed" { powerpc64*-*-* } } */
 
 #include 
 
Index: gcc/testsuite/gcc.dg/torture/inf-compare-3.c
===
--- gcc/testsuite/gcc.dg/torture/inf-compare-3.c(revision 256541)
+++ gcc/testsuite/gcc.dg/torture/inf-compare-3.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-add-options ieee } */
 /* { dg-require-effective-target fenv_exceptions } */
+/* { dg-skip-if "remove this when pr58684 is fixed" { powerpc64*-*-* } } */
 
 #include 
 
Index: gcc/testsuite/gcc.dg/torture/inf-compare-4.c
===
--- gcc/testsuite/gcc.dg/torture/inf-compare-4.c(revision 256541)
+++ gcc/testsuite/gcc.dg/torture/inf-compare-4.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-add-options ieee } */
 /* { dg-require-effective-target fenv_exceptions } */
+/* { dg-skip-if "remove this when pr58684 is fixed" { powerpc64*-*-* } } */
 
 #include 

-- 

-Bill Seurer



Re: [patch, libfortran] AMD-specific versions of library matmul

2017-05-26 Thread Bill Seurer

On 05/26/2017 12:41 AM, Andrew Pinski wrote:

On Thu, May 25, 2017 at 6:43 PM, Jerry DeLisle <jvdeli...@charter.net> wrote:

On 05/25/2017 02:57 PM, Thomas Koenig wrote:


Hi everybody,

I have committed the patch (with the corrections for the name)
as rev 248472.

The infrastructure is in place, so we will be able to make
any fine-tuning easily.

Regards

 Thomas



Based on my testing I think it is close enough as is.


This patch most likely broke all non-x86 targets:
configure: error: conditional "HAVE_AVX128" was never defined.
Usually this means the macro was only invoked conditionally.
Makefile:19843: recipe for target 'configure-target-libgfortran' failed
make[1]: *** [configure-target-libgfortran] Error 1
make[1]: *** Waiting for unfinished jobs


Yup, this is definitely what broke (most-) everything.  248471 worked 
fine and then the above error starting with 248472.

--

-Bill Seurer



[PATCH, rs6000] pr80482 Relax vector builtin parameter checks

2017-04-24 Thread Bill Seurer
[PATCH, rs6000] pr80482 Relax vector builtin parameter checks

This patch changes the parameter testing for powerpc vector builtins to relax
the existing requirement that the parameters be identical to instead that they
be compatible.  This allows for mixing parameters with differing qualified
(const, volatile, etc.) types.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80482 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64be-unknown-linux-gnu with no regressions.  Is this ok for trunk?

[gcc]

2017-04-24  Bill Seurer  <seu...@linux.vnet.ibm.com>

* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Change
type checks to test for compatibility instead of equality.

[gcc/testsuite]

2017-04-24  Bill Seurer  <seu...@linux.vnet.ibm.com>

* gcc.target/powerpc/vec-constvolatile.c: New test.


Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 247111)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -5595,11 +5595,11 @@ altivec_resolve_overloaded_builtin (location_t loc
   tree arg1 = (*arglist)[1];
   tree arg1_type = TREE_TYPE (arg1);
 
-  /* Both arguments must be vectors and the types must match.  */
-  if (arg0_type != arg1_type)
-   goto bad;
+  /* Both arguments must be vectors and the types must be compatible.  */
   if (TREE_CODE (arg0_type) != VECTOR_TYPE)
goto bad;
+  if (!lang_hooks.types_compatible_p (arg0_type, arg1_type))
+   goto bad;
 
   switch (TYPE_MODE (TREE_TYPE (arg0_type)))
{
@@ -5610,8 +5610,8 @@ altivec_resolve_overloaded_builtin (location_t loc
  case TImode:
{
  /* For scalar types just use a multiply expression.  */
- return fold_build2_loc (loc, MULT_EXPR, TREE_TYPE (arg0),
-   arg0, arg1);
+ return fold_build2_loc (loc, MULT_EXPR, TREE_TYPE (arg0), arg0,
+ fold_convert (TREE_TYPE (arg0), arg1));
}
  case SFmode:
{
@@ -5655,13 +5655,12 @@ altivec_resolve_overloaded_builtin (location_t loc
  || (TYPE_MODE (TREE_TYPE (arg0_type)) == SFmode)
  || (TYPE_MODE (TREE_TYPE (arg0_type)) == DFmode))
{
- /* Both arguments must be vectors and the types must match.  */
- if (arg0_type != arg1_type)
-   goto bad;
+ /* Both arguments must be vectors and the types must be compatible.  
*/
  if (TREE_CODE (arg0_type) != VECTOR_TYPE)
goto bad;
+ if (!lang_hooks.types_compatible_p (arg0_type, arg1_type))
+   goto bad;
 
-
  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
{
  /* vec_cmpneq (va, vb) == vec_nor (vec_cmpeq (va, vb),
@@ -5720,11 +5719,12 @@ altivec_resolve_overloaded_builtin (location_t loc
   tree arg2_type = TREE_TYPE (arg2);
 
   /* All 3 arguments must be vectors of (signed or unsigned) (int or
- __int128) and the types must match.  */
-  if ((arg0_type != arg1_type) || (arg1_type != arg2_type))
-   goto bad;
+ __int128) and the types must be compatible.  */
   if (TREE_CODE (arg0_type) != VECTOR_TYPE)
goto bad;
+  if (!lang_hooks.types_compatible_p (arg0_type, arg1_type) ||
+ !lang_hooks.types_compatible_p (arg1_type, arg2_type))
+   goto bad;
 
   switch (TYPE_MODE (TREE_TYPE (arg0_type)))
{
@@ -5783,11 +5783,13 @@ altivec_resolve_overloaded_builtin (location_t loc
   tree arg2_type = TREE_TYPE (arg2);
 
   /* All 3 arguments must be vectors of (signed or unsigned) (int or
-   __int128) and the types must match.  */
-  if (arg0_type != arg1_type || arg1_type != arg2_type)
-   goto bad;
+   __int128) and the types must be compatible.  */
+  /* Both arguments must be vectors and the types must be compatible.  */
   if (TREE_CODE (arg0_type) != VECTOR_TYPE)
goto bad;
+  if (!lang_hooks.types_compatible_p (arg0_type, arg1_type) ||
+ !lang_hooks.types_compatible_p (arg1_type, arg2_type))
+   goto bad;
 
   switch (TYPE_MODE (TREE_TYPE (arg0_type)))
{
Index: gcc/testsuite/gcc.target/powerpc/vec-constvolatile.c
===
--- gcc/testsuite/gcc.target/powerpc/vec-constvolatile.c(revision 0)
+++ gcc/testsuite/gcc.target/powerpc/vec-constvolatile.c(working copy)
@@ -0,0 +1,31 @@
+/* Test that const and volatile qualifiers can mix on vec_mul operands.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec -mvsx" } */
+
+#include 
+
+void P() {
+  const volatile vector float cvva = vec_splats(0.00187682f);
+  volatile vector float vva = vec_splats(0.00187682f);
+  const vector 

Re: [PATCH, rs6000] pr65479 Add -fasynchronous-unwind-tables when the -fsanitize=address option is seen.

2017-01-06 Thread Bill Seurer

On 01/06/2017 01:48 AM, Segher Boessenkool wrote:

On Thu, Jan 05, 2017 at 01:21:40PM -0600, Bill Seurer wrote:

(backport from trunk to gcc 6)

This patch adds the -fasynchronous-unwind-tables option to compilations when
the -fsanitize=address option is seen but not if any
-fasynchronous-unwind-tables options were already specified.
-fasynchronous-unwind-tables causes a full strack trace to be produced when
the sanitizer detects an error.  Without the full trace several of the asan
test cases fail on powerpc.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu,
powerpc64be-unknown-linux-gnu, and x86_64-pc-linux-gnu with no regressions.
Is this ok for trunk?


It already is on trunk...  You mean the branches :-)  It is okay for all
open release branches (i.e., 5 and 6).  Or does it not apply to GCC 5?

Thanks,


Segher


Yes, I meant the 6 branch.  I only tried it on 6 but it should be fine 
for 5 too.




2017-01-05  Bill Seurer  <seu...@linux.vnet.ibm.com>

PR sanitizer/65479
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
-fasynchronous-unwind-tables option when -fsanitize=address is
specified.





--

-Bill Seurer



[PATCH, rs6000] pr65479 Add -fasynchronous-unwind-tables when the -fsanitize=address option is seen.

2017-01-05 Thread Bill Seurer
[PATCH, rs6000] pr65479 Add -fasynchronous-unwind-tables when the 
-fsanitize=address option is seen.

(backport from trunk to gcc 6)

This patch adds the -fasynchronous-unwind-tables option to compilations when
the -fsanitize=address option is seen but not if any
-fasynchronous-unwind-tables options were already specified.
-fasynchronous-unwind-tables causes a full strack trace to be produced when
the sanitizer detects an error.  Without the full trace several of the asan
test cases fail on powerpc.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu,
powerpc64be-unknown-linux-gnu, and x86_64-pc-linux-gnu with no regressions.
Is this ok for trunk?

[gcc]

2017-01-05  Bill Seurer  <seu...@linux.vnet.ibm.com>

PR sanitizer/65479
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add
-fasynchronous-unwind-tables option when -fsanitize=address is
specified.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 244105)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -3750,6 +3750,13 @@ rs6000_option_override_internal (bool global_init_
   && !global_options_set.x_flag_ira_loop_pressure)
 flag_ira_loop_pressure = 1;
 
+  /* -fsanitize=address needs to turn on -fasynchronous-unwind-tables in order
+ for tracebacks to be complete but not if any -fasynchronous-unwind-tables
+ options were already specified.  */
+  if (flag_sanitize & SANITIZE_USER_ADDRESS
+  && !global_options_set.x_flag_asynchronous_unwind_tables)
+flag_asynchronous_unwind_tables = 1;
+
   /* Set the pointer size.  */
   if (TARGET_64BIT)
 {
-- 

-Bill Seurer



[PATCH, v2, rs6000] pr65479 Add -fasynchronous-unwind-tables when the -fsanitize=address option is seen

2016-12-21 Thread Bill Seurer
[PATCH, v2, rs6000] pr65479 Add -fasynchronous-unwind-tables when the 
-fsanitize=address option is seen.

All feedback from the earlier version has been taken into account now.

This patch adds the -fasynchronous-unwind-tables option to compilations when
the -fsanitize=address option is seen but not if any
-fasynchronous-unwind-tables options were already specified.
-fasynchronous-unwind-tables causes a full strack trace to be produced when
the sanitizer detects an error.  Without the full trace several of the asan
test cases fail on powerpc.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu,
powerpc64be-unknown-linux-gnu, and x86_64-pc-linux-gnu with no regressions.
Is this ok for trunk?

[gcc]

2016-12-21  Bill Seurer  <seu...@linux.vnet.ibm.com>

PR sanitizer/65479
* config/rs6000/rs6000.c (rs6000_option_override_internal): Add 
-fasynchronous-unwind-tables option when -fsanitize=address is
specified.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 243830)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -3858,6 +3858,13 @@ rs6000_option_override_internal (bool global_init_
   && !global_options_set.x_flag_ira_loop_pressure)
 flag_ira_loop_pressure = 1;
 
+  /* -fsanitize=address needs to turn on -fasynchronous-unwind-tables in order
+ for tracebacks to be complete but not if any -fasynchronous-unwind-tables
+ options were already specified.  */
+  if (flag_sanitize & SANITIZE_USER_ADDRESS
+  && !global_options_set.x_flag_asynchronous_unwind_tables)
+flag_asynchronous_unwind_tables = 1;
+
   /* Set the pointer size.  */
   if (TARGET_64BIT)
 {



[PATCH, rs6000] pr65479 Add -fasynchronous-unwind-tables when the -fsanitize=address option is seen

2016-12-06 Thread Bill Seurer
[PATCH, rs6000] pr65479 Add -fasynchronous-unwind-tables when the 
-fsanitize=address option is seen.

This patch adds the -fasynchronous-unwind-tables option to compilations when
the -fsanitize=address option is seen.  -fasynchronous-unwind-tables causes a
full strack trace to be produced when the sanitizer detects an error.  Without
the full trace several of the asan test cases fail on ppc64.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu,
powerpc64be-unknown-linux-gnu, and x86_64-pc-linux-gnu with no regressions.
Is this ok for trunk?

[gcc]

2016-12-06  Bill Seurer  <seu...@linux.vnet.ibm.com>

PR sanitizer/65479
* gcc/config/rs6000/rs6000.c: Add -fasynchronous-unwind-tables option 
when
-fsanitize=address is specified.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 243308)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -5204,6 +5204,11 @@ rs6000_option_override (void)
 {
   (void) rs6000_option_override_internal (true);
 
+  /* -fsanitize=address needs to turn on -fasynchronous-unwind-tables for
+ ppc64 in order for tracebacks to be complete.  */
+  if (global_options.x_flag_sanitize & SANITIZE_USER_ADDRESS)
+global_options.x_flag_asynchronous_unwind_tables = 1;
+
   /* Register machine-specific passes.  This needs to be done at start-up.
  It's convenient to do it here (like i386 does).  */
   opt_pass *pass_analyze_swaps = make_pass_analyze_swaps (g);



Re: [PATCH, rs6000] pr65479 Add option to fix failing asan test cases.

2016-10-17 Thread Bill Seurer

On 10/14/2016 04:59 PM, Segher Boessenkool wrote:

On Fri, Oct 14, 2016 at 02:37:42PM -0500, Bill Seurer wrote:

[PATCH, rs6000] pr65479 Add option to fix failing asan test cases.

This patch adds the -fasynchronous-unwind-tables option to several of the asan
test cases.  The option causes a full strack trace to be produced when the
sanitizer detects an error.  Without the full trace the 3 test cases fail.


Should we enable this whenever asan is used, instead?  Not just in the
testsuite?  And is this actually PowerPC-specific?


It is needed on these tests because of how they check the traceback 
stack looking for specific functions.  Without the option only the first 
(triggering) function is included.


I don't know if the option is power specific but on x86 for instance the 
traceback gives all the functions without the option.

--

-Bill Seurer



[PATCH, rs6000] pr65479 Add option to fix failing asan test cases.

2016-10-14 Thread Bill Seurer
[PATCH, rs6000] pr65479 Add option to fix failing asan test cases.

This patch adds the -fasynchronous-unwind-tables option to several of the asan
test cases.  The option causes a full strack trace to be produced when the
sanitizer detects an error.  Without the full trace the 3 test cases fail.

See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65479 for more information.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu,
powerpc64be-unknown-linux-gnu, and x86_64-pc-linux-gnu with no regressions.
Is this ok for trunk?

[gcc/testsuite]

2016-10-14  Bill Seurer  <seu...@linux.vnet.ibm.com>

c-c++-common/asan/misalign-1.c: Add option for powerpc.
c-c++-common/asan/misalign-2.c: Add option for powerpc.
c-c++-common/asan/null-deref-1.c: Add option for powerpc.

Index: gcc/testsuite/c-c++-common/asan/misalign-1.c
===
--- gcc/testsuite/c-c++-common/asan/misalign-1.c(revision 241174)
+++ gcc/testsuite/c-c++-common/asan/misalign-1.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run { target { ilp32 || lp64 } } } */
 /* { dg-options "-O2" } */
 /* { dg-additional-options "-fno-omit-frame-pointer" { target *-*-darwin* } } 
*/
+/* { dg-additional-options "-fasynchronous-unwind-tables" { target { 
powerpc*-*-linux* } } } */
 /* { dg-shouldfail "asan" } */
 
 struct S { int i; } __attribute__ ((packed));
@@ -39,5 +40,5 @@ main ()
 /* { dg-output "ERROR: AddressSanitizer:\[^\n\r]*on address\[^\n\r]*" } */
 /* { dg-output "0x\[0-9a-f\]+ at pc 0x\[0-9a-f\]+ bp 0x\[0-9a-f\]+ sp 
0x\[0-9a-f\]+\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*READ of size 4 at 0x\[0-9a-f\]+ thread 
T0\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "#0 0x\[0-9a-f\]+ +(in 
_*foo(\[^\n\r]*misalign-1.c:1\[01]|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r)" } 
*/
-/* { dg-output "#1 0x\[0-9a-f\]+ +(in _*main 
(\[^\n\r]*misalign-1.c:3\[45]|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r)" } */
+/* { dg-output "#0 0x\[0-9a-f\]+ +(in 
_*foo(\[^\n\r]*misalign-1.c:1\[12]|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r)" } 
*/
+/* { dg-output "#1 0x\[0-9a-f\]+ +(in _*main 
(\[^\n\r]*misalign-1.c:3\[56]|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r)" } */
Index: gcc/testsuite/c-c++-common/asan/misalign-2.c
===
--- gcc/testsuite/c-c++-common/asan/misalign-2.c(revision 241174)
+++ gcc/testsuite/c-c++-common/asan/misalign-2.c(working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run { target { ilp32 || lp64 } } } */
 /* { dg-options "-O2" } */
 /* { dg-additional-options "-fno-omit-frame-pointer" { target *-*-darwin* } } 
*/
+/* { dg-additional-options "-fasynchronous-unwind-tables" { target { 
powerpc*-*-linux* } } } */
 /* { dg-shouldfail "asan" } */
 
 struct S { int i; } __attribute__ ((packed));
@@ -39,5 +40,5 @@ main ()
 /* { dg-output "ERROR: AddressSanitizer:\[^\n\r]*on address\[^\n\r]*" } */
 /* { dg-output "0x\[0-9a-f\]+ at pc 0x\[0-9a-f\]+ bp 0x\[0-9a-f\]+ sp 
0x\[0-9a-f\]+\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*READ of size 4 at 0x\[0-9a-f\]+ thread 
T0\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "#0 0x\[0-9a-f\]+ +(in 
_*baz(\[^\n\r]*misalign-2.c:2\[23]|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r)" } 
*/
-/* { dg-output "#1 0x\[0-9a-f\]+ +(in _*main 
(\[^\n\r]*misalign-2.c:3\[45]|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r)" } */
+/* { dg-output "#0 0x\[0-9a-f\]+ +(in 
_*baz(\[^\n\r]*misalign-2.c:2\[34]|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r)" } 
*/
+/* { dg-output "#1 0x\[0-9a-f\]+ +(in _*main 
(\[^\n\r]*misalign-2.c:3\[56]|\[^\n\r]*:0)|\[(\]).*(\n|\r\n|\r)" } */
Index: gcc/testsuite/c-c++-common/asan/null-deref-1.c
===
--- gcc/testsuite/c-c++-common/asan/null-deref-1.c  (revision 241174)
+++ gcc/testsuite/c-c++-common/asan/null-deref-1.c  (working copy)
@@ -1,6 +1,7 @@
 /* { dg-do run } */
 /* { dg-options "-fno-omit-frame-pointer -fno-shrink-wrap" } */
 /* { dg-additional-options "-mno-omit-leaf-frame-pointer" { target { i?86-*-* 
x86_64-*-* } } } */
+/* { dg-additional-options "-fasynchronous-unwind-tables" { target { 
powerpc*-*-linux* } } } */
 /* { dg-shouldfail "asan" } */
 
 __attribute__((noinline, noclone))
@@ -18,5 +19,5 @@ int main()
 
 /* { dg-output "ERROR: AddressSanitizer:? SEGV on unknown address\[^\n\r]*" } 
*/
 /* { dg-output "0x\[0-9a-f\]+ \[^\n\r]*pc 0x\[0-9a-f\]+\[^\n\r]*(\n|\r\n|\r)" 
} */
-/* { dg-output "\[^\n\r]*#0 0x\[0-9a-f\]+ +(in \[^\n\r]*NullDeref\[^\n\r]* 
(\[^\n\r]*null-deref-1.c:10|\[^\n\r]*:0)|\[(\])\[^\n\r]*(\n|\r\n|\r)" } */
-/* { dg-output "#1 0x\[0-9a-f\]+ +(in _*main 
(\[^\n\r]*null-deref

Re: [PATCHv3][ARM] -mpure-code option for ARM

2016-09-22 Thread Bill Seurer

This patch breaks compilation on power:

g++ -fno-PIE -c   -g -O2 -DIN_GCC -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common 
-DHAVE_CONFIG_H -I. -I. -I/home/seurer/gcc/gcc-test2/gcc 
-I/home/seurer/gcc/gcc-test2/gcc/. 
-I/home/seurer/gcc/gcc-test2/gcc/../include 
-I/home/seurer/gcc/gcc-test2/gcc/../libcpp/include 
-I/home/seurer/gcc/gcc-test2/gcc/../libdecnumber 
-I/home/seurer/gcc/gcc-test2/gcc/../libdecnumber/dpd -I../libdecnumber 
-I/home/seurer/gcc/gcc-test2/gcc/../libbacktrace   -o rs6000.o -MT 
rs6000.o -MMD -MP -MF ./.deps/rs6000.TPo 
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c

In file included from /home/seurer/gcc/gcc-test2/gcc/target-def.h:106:0,
 from 
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c:77:
./target-hooks-def.h:92:38: error: 'hook_uint_uintp_false' was not 
declared in this scope

 #define TARGET_ASM_ELF_FLAGS_NUMERIC hook_uint_uintp_false
  ^
./target-hooks-def.h:2205:5: note: in expansion of macro 
'TARGET_ASM_ELF_FLAGS_NUMERIC'

 TARGET_ASM_ELF_FLAGS_NUMERIC, \
 ^~~~
./target-hooks-def.h:1792:5: note: in expansion of macro 'TARGET_ASM_OUT'
 TARGET_ASM_OUT, \
 ^~
/home/seurer/gcc/gcc-test2/gcc/config/rs6000/rs6000.c:40709:29: note: in 
expansion of macro 'TARGET_INITIALIZER'

 struct gcc_target targetm = TARGET_INITIALIZER;
 ^~
make[2]: *** [rs6000.o] Error 1


On 09/22/16 12:04, Andre Vieira (lists) wrote:

On 22/09/16 16:28, Richard Earnshaw (lists) wrote:

On 22/09/16 16:04, Andre Vieira (lists) wrote:


I reworked the patch according to the comments above.

Is this OK?

gcc/ChangeLog:
2016-09-22  Andre Vieira  <andre.simoesdiasvie...@arm.com>
Terry Guo  <terry@arm.com>

* target.def (elf_flags_numeric): New target hook.
* targhooks.h (default_asm_elf_flags_numeric): New.
* varasm.c (default_asm_elf_flags_numeric): New.
  (default_elf_asm_named_section): Use new target hook.
* config/arm/arm.opt (mpure-code): New.
* config/arm/arm.h (SECTION_ARM_PURECODE): New.
* config/arm/arm.c (arm_asm_init_sections): Add section
  attribute to default text section if -mpure-code.
  (arm_option_check_internal): Diagnose use of option with
  non supported targets and/or options.
  (arm_asm_elf_flags_numeric): New.
  (arm_function_section): New.
  (arm_elf_section_type_flags): New.
* config/arm/elf.h (JUMP_TABLES_IN_TEXT_SECTION): Disable
  for -mpure-code.
* gcc/doc/texi (TARGET_ASM_ELF_FLAGS_NUMERIC): New.
* gcc/doc/texi.in (TARGET_ASM_ELF_FLAGS_NUMERIC): Likewise.



gcc/testsuite/ChangeLog:
2016-09-22  Andre Vieira  <andre.simoesdiasvie...@arm.com>
Terry Guo  <terry@arm.com>

* gcc.target/arm/pure-code/ffunction-sections.c: New.
* gcc.target/arm/pure-code/no-literal-pool.c: New.
* gcc.target/arm/pure-code/pure-code.exp: New.




I missed this last time around, but please can you wrap references to
SHF_ARM_PURECODE in the documentation with @code{...}.

OK with that change.

R.


Done. Committed as revision r240379.




--

-Bill Seurer



[PATCH, rs6000] Add support for char, short, and int versions of vec_mul

2016-06-07 Thread Bill Seurer
This patch adds support for the missing versions of the vec_mul altivec
builtins from the Power Architecture 64-Bit ELF V2 ABI OpenPOWER ABI for
Linux Supplement (16 July 2015 Version 1.1). There are many of the builtins
that are missing and this is part of a series of patches to add them.

There aren't instructions for the {un}signed char, {un}signed short, and
{un}signed int versions of vec_mul so the output code is built from other
built-ins and operations that do have instructions.

The new test case is an executable test which verifies that the generated
code produces expected values. C macros were used so that the same
test case could be used for all the various supported types.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu with no regressions. Is this ok for trunk?

[gcc]

2016-06-07  Bill Seurer  <seu...@linux.vnet.ibm.com>

* config/rs6000/altivec.h: Add __builtin_vec_mul.
* config/rs6000/rs6000-builtin.def (vec_mul): Change vec_mul to a
special case Altivec builtin.
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Remove
VSX_BUILTIN_VEC_MUL (replaced with special case code).
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Add
code for ALTIVEC_BUILTIN_VEC_MUL.
* config/rs6000/rs6000.c (altivec_init_builtins): Add definition
for __builtin_vec_mul.

[gcc/testsuite]

2016-06-07  Bill Seurer  <seu...@linux.vnet.ibm.com>

* gcc.target/powerpc/vec-mul.c: New test.


Index: gcc/config/rs6000/altivec.h
===
--- gcc/config/rs6000/altivec.h (revision 237175)
+++ gcc/config/rs6000/altivec.h (working copy)
@@ -229,6 +229,7 @@
 #define vec_mladd __builtin_vec_mladd
 #define vec_msum __builtin_vec_msum
 #define vec_msums __builtin_vec_msums
+#define vec_mul __builtin_vec_mul
 #define vec_mule __builtin_vec_mule
 #define vec_mulo __builtin_vec_mulo
 #define vec_nor __builtin_vec_nor
Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 237175)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -1300,6 +1300,7 @@ BU_ALTIVEC_OVERLOAD_X (LVRX, "lvrx")
 BU_ALTIVEC_OVERLOAD_X (LVRXL, "lvrxl")
 BU_ALTIVEC_OVERLOAD_X (LVSL,  "lvsl")
 BU_ALTIVEC_OVERLOAD_X (LVSR,  "lvsr")
+BU_ALTIVEC_OVERLOAD_X (MUL,   "mul")
 BU_ALTIVEC_OVERLOAD_X (PROMOTE,   "promote")
 BU_ALTIVEC_OVERLOAD_X (SLD,   "sld")
 BU_ALTIVEC_OVERLOAD_X (SPLAT, "splat")
@@ -1600,7 +1601,6 @@ BU_VSX_OVERLOAD_3V (XXPERMDI, "xxpermdi")
 BU_VSX_OVERLOAD_3V (XXSLDWI,  "xxsldwi")
 
 /* 2 argument VSX overloaded builtin functions.  */
-BU_VSX_OVERLOAD_2 (MUL, "mul")
 BU_VSX_OVERLOAD_2 (DIV, "div")
 BU_VSX_OVERLOAD_2 (XXMRGHW,  "xxmrghw")
 BU_VSX_OVERLOAD_2 (XXMRGLW,  "xxmrglw")
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 237175)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -1941,14 +1941,6 @@ const struct altivec_builtin_types altivec_overloa
 RS6000_BTI_unsigned_V16QI, RS6000_BTI_bool_V16QI, 
RS6000_BTI_unsigned_V16QI, 0 },
   { ALTIVEC_BUILTIN_VEC_VMINUB, ALTIVEC_BUILTIN_VMINUB,
 RS6000_BTI_unsigned_V16QI, RS6000_BTI_unsigned_V16QI, 
RS6000_BTI_bool_V16QI, 0 },
-  { VSX_BUILTIN_VEC_MUL, VSX_BUILTIN_XVMULSP,
-RS6000_BTI_V4SF, RS6000_BTI_V4SF, RS6000_BTI_V4SF, 0 },
-  { VSX_BUILTIN_VEC_MUL, VSX_BUILTIN_XVMULDP,
-RS6000_BTI_V2DF, RS6000_BTI_V2DF, RS6000_BTI_V2DF, 0 },
-  { VSX_BUILTIN_VEC_MUL, VSX_BUILTIN_MUL_V2DI,
-RS6000_BTI_V2DI, RS6000_BTI_V2DI, RS6000_BTI_V2DI, 0 },
-  { VSX_BUILTIN_VEC_MUL, VSX_BUILTIN_MUL_V2DI,
-RS6000_BTI_unsigned_V2DI, RS6000_BTI_unsigned_V2DI, 
RS6000_BTI_unsigned_V2DI, 0 },
   { ALTIVEC_BUILTIN_VEC_MULE, ALTIVEC_BUILTIN_VMULEUB,
 RS6000_BTI_unsigned_V8HI, RS6000_BTI_unsigned_V16QI, 
RS6000_BTI_unsigned_V16QI, 0 },
   { ALTIVEC_BUILTIN_VEC_MULE, ALTIVEC_BUILTIN_VMULESB,
@@ -4683,7 +4675,58 @@ assignment for unaligned loads and stores");
 warning (OPT_Wdeprecated, "vec_lvsr is deprecated for little endian; use \
 assignment for unaligned loads and stores");
 
+  if (fcode == ALTIVEC_BUILTIN_VEC_MUL)
+{
+  /* vec_mul needs to be special cased because there are no instructions
+for it for the {un}signed char, {un}signed short, and {un}signed int
+types.  */
+  if (nargs != 2)
+   {
+ error ("vec_mul only accepts 2 arguments");
+ return error_mark_node;
+   }
 
+  tree arg0 = (*arglist)[0];
+  tree arg0_type = TREE_TYPE (arg0);
+  tree arg1 = (*ar

Re: [PATCH, RS6000] Add support for the vec_cmpne altivec builtins

2016-05-25 Thread Bill Seurer

On 05/25/16 14:50, Segher Boessenkool wrote:

On Wed, May 25, 2016 at 10:37:43AM -0500, Bill Seurer wrote:

This patch adds support for the vec_cmpne altivec builtins from the Power
Architecture 64-Bit ELF V2 ABI OpenPOWER ABI for Linux Supplement (16 July
2015 Version 1.1). There are many of the builtins that are missing and this
is part of a series of patches to add them.

There aren't instructions for vec_cmpne so the output code is built from other
built-ins that do have instructions which in this case is the following.

vec_cmpneq (va, vb) == vec_nor (vec_cmpeq (va, vb), vec_cmpeq (va, vb))

The new test cases are executable tests which verify that the generated
code produces expected values. C macros were used so that the same
test case could be used for both the signed and unsigned versions of various
basic types. A separate executable test case is used for the long long versions
of vec_cmpne because of some differences in loading and storing the vectors.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu (power8) and
powerpc64-unknown-linux-gnu (both power7 and power8) with no regressions. Is
this ok for trunk?


Okay for trunk, thanks!  One formatting nit, one question...


+ /* call = vec_cmpeq (va, vb)
+result = vec_nor (call, call)
+  */


Please put the */ at the end of the last line, not on its own.


Will do.




--- gcc/testsuite/gcc.target/powerpc/vec-cmpne-long.c   (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/vec-cmpne-long.c   (working copy)
@@ -0,0 +1,110 @@
+/* { dg-do run { target { powerpc64*-*-* } } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-skip-if "do not override -mcpu" { powerpc*-*-* } { "-mcpu=*" } { 
"-mcpu=power8" } } */
+/* { dg-options "-mcpu=power8 -mpower8-vector -O3" } */


Just a question: does this need -O3 to work?


No, the opt level doesn't really matter for these tests because they 
aren't looking for specific code sequences.


--

-Bill Seurer



[PATCH, RS6000] Add support for the vec_cmpne altivec builtins

2016-05-25 Thread Bill Seurer
This patch adds support for the vec_cmpne altivec builtins from the Power
Architecture 64-Bit ELF V2 ABI OpenPOWER ABI for Linux Supplement (16 July
2015 Version 1.1). There are many of the builtins that are missing and this
is part of a series of patches to add them.

There aren't instructions for vec_cmpne so the output code is built from other
built-ins that do have instructions which in this case is the following.

vec_cmpneq (va, vb) == vec_nor (vec_cmpeq (va, vb), vec_cmpeq (va, vb))

The new test cases are executable tests which verify that the generated
code produces expected values. C macros were used so that the same
test case could be used for both the signed and unsigned versions of various
basic types. A separate executable test case is used for the long long versions
of vec_cmpne because of some differences in loading and storing the vectors.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu (power8) and
powerpc64-unknown-linux-gnu (both power7 and power8) with no regressions. Is
this ok for trunk?

[gcc]

2016-05-25  Bill Seurer  <seu...@linux.vnet.ibm.com>

* config/rs6000/altivec.h (vec_cmpne): Add #define for vec_cmpne.
* config/rs6000/rs6000-builtin.def (vec_cmpne): Add vec_cmpne as a
special case builtin.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Add
code for ALTIVEC_BUILTIN_VEC_CMPNE.
* config/rs6000/rs6000.c (altivec_init_builtins): Add definition
for __builtin_vec_cmpne.

[gcc/testsuite]

2016-05-25  Bill Seurer  <seu...@linux.vnet.ibm.com>

* gcc.target/powerpc/vec-cmpne.c: New test.
* gcc.target/powerpc/vec-cmpne-long.c: New test.


Index: gcc/config/rs6000/altivec.h
===
--- gcc/config/rs6000/altivec.h (revision 236702)
+++ gcc/config/rs6000/altivec.h (working copy)
@@ -196,6 +196,7 @@
 #define vec_andc __builtin_vec_andc
 #define vec_avg __builtin_vec_avg
 #define vec_cmpeq __builtin_vec_cmpeq
+#define vec_cmpne __builtin_vec_cmpne
 #define vec_cmpgt __builtin_vec_cmpgt
 #define vec_ctf __builtin_vec_ctf
 #define vec_dst __builtin_vec_dst
Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 236702)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -1282,6 +1282,7 @@ BU_ALTIVEC_OVERLOAD_P (VCMPGE_P,   "vcmpge_p")
 /* Overloaded Altivec builtins that are handled as special cases.  */
 BU_ALTIVEC_OVERLOAD_X (ADDE,  "adde")
 BU_ALTIVEC_OVERLOAD_X (ADDEC, "addec")
+BU_ALTIVEC_OVERLOAD_X (CMPNE, "cmpne")
 BU_ALTIVEC_OVERLOAD_X (CTF,   "ctf")
 BU_ALTIVEC_OVERLOAD_X (CTS,   "cts")
 BU_ALTIVEC_OVERLOAD_X (CTU,   "ctu")
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 236702)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -4675,6 +4675,66 @@ assignment for unaligned loads and stores");
 warning (OPT_Wdeprecated, "vec_lvsr is deprecated for little endian; use \
 assignment for unaligned loads and stores");
 
+
+  if (fcode == ALTIVEC_BUILTIN_VEC_CMPNE)
+{
+  /* vec_cmpne needs to be special cased because there are no instructions
+for it (prior to power 9).  */
+  if (nargs != 2)
+   {
+ error ("vec_cmpne only accepts 2 arguments");
+ return error_mark_node;
+   }
+
+  tree arg0 = (*arglist)[0];
+  tree arg0_type = TREE_TYPE (arg0);
+  tree arg1 = (*arglist)[1];
+  tree arg1_type = TREE_TYPE (arg1);
+
+  /* Both arguments must be vectors and the types must match.  */
+  if (arg0_type != arg1_type)
+   goto bad;
+  if (TREE_CODE (arg0_type) != VECTOR_TYPE)
+   goto bad;
+
+  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
+   {
+ /* vec_cmpneq (va, vb) == vec_nor (vec_cmpeq (va, vb),
+vec_cmpeq (va, vb)).  */
+ /* Note:  vec_nand also works but opt changes vec_nand's to vec_nor's
+anyway.  */
+ case QImode:
+ case HImode:
+ case SImode:
+ case DImode:
+ case TImode:
+ case SFmode:
+ case DFmode:
+  {
+ /* call = vec_cmpeq (va, vb)
+result = vec_nor (call, call)
+  */
+ vec<tree, va_gc> *params = make_tree_vector ();
+ vec_safe_push (params, arg0);
+ vec_safe_push (params, arg1);
+ tree call = altivec_resolve_overloaded_builtin
+   (loc, rs6000_builtin_decls[ALTIVEC_BUILTIN_VEC_CMPEQ], params);
+ /* Use save_expr to ensure that operands used more than once
+that may have side effects (like

[PATCH, rs6000] Fix compilation issue on power7 from r235577

2016-05-20 Thread Bill Seurer
This patch changes some of the dejagnu options to better restrict
where the test cases run so that they will no longer cause failures on
power7 machines.

Based on a subsequent patch I also updated the code formatting (indentation,
etc.) for the code from the original patch (r235577) in both the test cases
and in rs6000-c.c.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu (on both
power7 and power8) and powerpc64-unknown-linux-gnu (power8) with no
regressions. Is this ok for trunk?

[gcc]

2016-05-20  Bill Seurer  <seu...@linux.vnet.ibm.com>

* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Fix
code formatting in ALTIVEC_BUILTIN_VEC_ADDEC section.

[gcc/testsuite]

2016-05-20  Bill Seurer  <seu...@linux.vnet.ibm.com>

* gcc.target/powerpc/vec-addec.c: Change dejagnu options, fix code
  formatting.
* gcc.target/powerpc/vec-addec-int128.c: Change dejagnu options, fix 
code
  formatting.

Index: /home/seurer/gcc/gcc-checkin2/gcc/config/rs6000/rs6000-c.c
===
--- /home/seurer/gcc/gcc-checkin2/gcc/config/rs6000/rs6000-c.c  (revision 
236518)
+++ /home/seurer/gcc/gcc-checkin2/gcc/config/rs6000/rs6000-c.c  (working copy)
@@ -4622,37 +4622,41 @@ assignment for unaligned loads and stores");
   /* All 3 arguments must be vectors of (signed or unsigned) (int or
  __int128) and the types must match.  */
   if ((arg0_type != arg1_type) || (arg1_type != arg2_type))
-   goto bad; 
+   goto bad;
   if (TREE_CODE (arg0_type) != VECTOR_TYPE)
-   goto bad; 
+   goto bad;
 
   switch (TYPE_MODE (TREE_TYPE (arg0_type)))
{
- /* For {un}signed ints, 
-vec_adde (va, vb, carryv) == vec_add (vec_add (va, vb), 
-   vec_and (carryv, 0x1)).  */
+ /* For {un}signed ints,
+vec_adde (va, vb, carryv) == vec_add (vec_add (va, vb),
+  vec_and (carryv, 0x1)).  */
  case SImode:
{
- vec<tree, va_gc> *params = make_tree_vector();
+ vec<tree, va_gc> *params = make_tree_vector ();
  vec_safe_push (params, arg0);
  vec_safe_push (params, arg1);
- tree call = altivec_resolve_overloaded_builtin
-(loc, rs6000_builtin_decls[ALTIVEC_BUILTIN_VEC_ADD], params);
- tree const1 = build_vector_from_val (arg0_type, 
-build_int_cstu(TREE_TYPE (arg0_type), 1));
- tree and_expr = fold_build2_loc (loc, BIT_AND_EXPR,
-   arg0_type, arg2, const1);
- params = make_tree_vector();
+ tree add_builtin = rs6000_builtin_decls[ALTIVEC_BUILTIN_VEC_ADD];
+ tree call = altivec_resolve_overloaded_builtin (loc, add_builtin,
+ params);
+ tree const1 = build_int_cstu (TREE_TYPE (arg0_type), 1);
+ tree ones_vector = build_vector_from_val (arg0_type, const1);
+ tree and_expr = fold_build2_loc (loc, BIT_AND_EXPR, arg0_type,
+  arg2, ones_vector);
+ params = make_tree_vector ();
  vec_safe_push (params, call);
  vec_safe_push (params, and_expr);
- return altivec_resolve_overloaded_builtin
-(loc, rs6000_builtin_decls[ALTIVEC_BUILTIN_VEC_ADD], params);
+ return altivec_resolve_overloaded_builtin (loc, add_builtin,
+params);
}
  /* For {un}signed __int128s use the vaddeuqm instruction
directly.  */
  case TImode:
-   return altivec_resolve_overloaded_builtin
-   (loc, rs6000_builtin_decls[P8V_BUILTIN_VEC_VADDEUQM], arglist);
+   {
+ tree adde_bii = rs6000_builtin_decls[P8V_BUILTIN_VEC_VADDEUQM];
+ return altivec_resolve_overloaded_builtin (loc, adde_bii,
+arglist);
+   }
 
  /* Types other than {un}signed int and {un}signed __int128
are errors.  */
@@ -4839,9 +4843,9 @@ assignment for unaligned loads and stores");
   arg1_type = TREE_TYPE (arg1);
 
   if (TREE_CODE (arg1_type) != VECTOR_TYPE)
-   goto bad; 
+   goto bad;
   if (!INTEGRAL_TYPE_P (TREE_TYPE (arg2)))
-   goto bad; 
+   goto bad;
 
   /* If we are targeting little-endian, but -maltivec=be has been
 specified to override the element order, adjust the element
@@ -4942,9 +4946,9 @@ assignment for unaligned loads and stores");
   arg2 = (*arglist)[2];
 
   if (TREE_CODE (arg1_type) != VECTOR_TYPE)
-   goto bad; 
+   goto bad;
   if (!INTEGRAL_TYPE_P (TREE_TYPE (arg2

Re: [PATCH, rs6000] Add support for int versions of vec_addec

2016-05-19 Thread Bill Seurer
Here is an updated patch addressing all of Segher's comments:

This patch adds support for the signed and unsigned int versions of the
vec_addec altivec builtins from the Power Architecture 64-Bit ELF V2 ABI
OpenPOWER ABI for Linux Supplement (16 July 2015 Version 1.1). There are
many of the builtins that are missing and this is part of a series
of patches to add them.

There aren't instructions for the int versions of vec_addec so the
output code is built from other built-ins that do have instructions
which in this case is the following.

vec_addec (va, vb, carryv) == vec_or (vec_addc (va, vb),
vec_addc(vec_add(va, vb),
 vec_and (carryv, 0x1)))

The new test cases are executable tests which verify that the generated
code produces expected values. C macros were used so that the same
test case could be used for both the signed and unsigned versions. An
extra executable test case is also included to ensure that the modified
support for the __int128 versions of vec_addec is not broken. The same
test case could not be used for both int and __int128 because of some
differences in loading and storing the vectors.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu with no regressions. Is this ok for trunk?

[gcc]

2016-05-19  Bill Seurer  <seu...@linux.vnet.ibm.com>

* config/rs6000/rs6000-builtin.def (vec_addec): Change vec_addec to a
special case builtin.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Add
support for ALTIVEC_BUILTIN_VEC_ADDEC.
* config/rs6000/rs6000.c (altivec_init_builtins): Add definition
for __builtin_vec_addec.

[gcc/testsuite]

2016-05-19  Bill Seurer  <seu...@linux.vnet.ibm.com>

* gcc.target/powerpc/vec-addec.c: New test.
* gcc.target/powerpc/vec-addec-int128.c: New test.


Index: /home/seurer/gcc/gcc-checkin/gcc/config/rs6000/rs6000-builtin.def
===
--- /home/seurer/gcc/gcc-checkin/gcc/config/rs6000/rs6000-builtin.def   
(revision 236484)
+++ /home/seurer/gcc/gcc-checkin/gcc/config/rs6000/rs6000-builtin.def   
(working copy)
@@ -991,7 +991,6 @@ BU_ALTIVEC_X (VEC_EXT_V4SF, "vec_ext_v4sf", CO
before we get to the point about classifying the builtin type.  */
 
 /* 3 argument Altivec overloaded builtins.  */
-BU_ALTIVEC_OVERLOAD_3 (ADDEC, "addec")
 BU_ALTIVEC_OVERLOAD_3 (MADD,   "madd")
 BU_ALTIVEC_OVERLOAD_3 (MADDS,  "madds")
 BU_ALTIVEC_OVERLOAD_3 (MLADD,  "mladd")
@@ -1177,6 +1176,7 @@ BU_ALTIVEC_OVERLOAD_P (VCMPGE_P,   "vcmpge_p")
 
 /* Overloaded Altivec builtins that are handled as special cases.  */
 BU_ALTIVEC_OVERLOAD_X (ADDE,  "adde")
+BU_ALTIVEC_OVERLOAD_X (ADDEC, "addec")
 BU_ALTIVEC_OVERLOAD_X (CTF,   "ctf")
 BU_ALTIVEC_OVERLOAD_X (CTS,   "cts")
 BU_ALTIVEC_OVERLOAD_X (CTU,   "ctu")
Index: /home/seurer/gcc/gcc-checkin/gcc/config/rs6000/rs6000-c.c
===
--- /home/seurer/gcc/gcc-checkin/gcc/config/rs6000/rs6000-c.c   (revision 
236484)
+++ /home/seurer/gcc/gcc-checkin/gcc/config/rs6000/rs6000-c.c   (working copy)
@@ -4661,6 +4661,86 @@ assignment for unaligned loads and stores");
}
 }
 
+  if (fcode == ALTIVEC_BUILTIN_VEC_ADDEC)
+{
+  /* vec_addec needs to be special cased because there is no instruction
+   for the {un}signed int version.  */
+  if (nargs != 3)
+   {
+ error ("vec_addec only accepts 3 arguments");
+ return error_mark_node;
+   }
+
+  tree arg0 = (*arglist)[0];
+  tree arg0_type = TREE_TYPE (arg0);
+  tree arg1 = (*arglist)[1];
+  tree arg1_type = TREE_TYPE (arg1);
+  tree arg2 = (*arglist)[2];
+  tree arg2_type = TREE_TYPE (arg2);
+
+  /* All 3 arguments must be vectors of (signed or unsigned) (int or
+   __int128) and the types must match.  */
+  if (arg0_type != arg1_type || arg1_type != arg2_type)
+   goto bad; 
+  if (TREE_CODE (arg0_type) != VECTOR_TYPE)
+   goto bad; 
+
+  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
+   {
+ /* For {un}signed ints, 
+ vec_addec (va, vb, carryv) ==
+   vec_or (vec_addc (va, vb),
+   vec_addc(vec_add(va, vb),
+vec_and (carryv, 0x1))).  */
+ case SImode:
+   {
+   /* Use save_expr to ensure that operands used more than once
+   that may have side effects (like calls) are only evaluated
+   once.  */
+   arg0 = save_expr(arg0);
+   arg1 = save_expr(arg1);
+   vec<tree, va_gc> *params = make_tree_vector ();
+   vec_sa

[PATCH, rs6000] Add support for int versions of vec_addec

2016-05-06 Thread Bill Seurer
This patch adds support for the signed and unsigned int versions of the
vec_addec altivec builtins from the Power Architecture 64-Bit ELF V2 ABI
OpenPOWER ABI for Linux Supplement (16 July 2015 Version 1.1). There are
many of the builtins that are missing and this is part of a series
of patches to add them.

There aren't instructions for the int versions of vec_addec so the
output code is built from other built-ins that do have instructions
which in this case is the following.

vec_addec (va, vb, carryv) == vec_or (vec_addc (va, vb),
vec_addc(vec_add(va, vb),
 vec_and (carryv, 0x1)))

The new test cases are executable tests which verify that the generated
code produces expected values. C macros were used so that the same
test case could be used for both the signed and unsigned versions. An
extra executable test case is also included to ensure that the modified
support for the __int128 versions of vec_addec is not broken. The same
test case could not be used for both int and __int128 because of some
differences in loading and storing the vectors.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu with no regressions. Is this ok for trunk?

[gcc]

2016-05-06  Bill Seurer  <seu...@linux.vnet.ibm.com>

* config/rs6000/rs6000-builtin.def (vec_addec): Change vec_addec to a
special case builtin.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Add
support for ALTIVEC_BUILTIN_VEC_ADDEC.
* config/rs6000/rs6000.c (altivec_init_builtins): Add definition
for __builtin_vec_addec.

[gcc/testsuite]

2016-05-06  Bill Seurer  <seu...@linux.vnet.ibm.com>

* gcc.target/powerpc/vec-addec.c: New test.
* gcc.target/powerpc/vec-addec-int128.c: New test.

Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 235962)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -951,7 +951,6 @@ BU_ALTIVEC_X (VEC_EXT_V4SF, "vec_ext_v4sf", CO
before we get to the point about classifying the builtin type.  */
 
 /* 3 argument Altivec overloaded builtins.  */
-BU_ALTIVEC_OVERLOAD_3 (ADDEC, "addec")
 BU_ALTIVEC_OVERLOAD_3 (MADD,   "madd")
 BU_ALTIVEC_OVERLOAD_3 (MADDS,  "madds")
 BU_ALTIVEC_OVERLOAD_3 (MLADD,  "mladd")
@@ -1137,6 +1136,7 @@ BU_ALTIVEC_OVERLOAD_P (VCMPGE_P,   "vcmpge_p")
 
 /* Overloaded Altivec builtins that are handled as special cases.  */
 BU_ALTIVEC_OVERLOAD_X (ADDE,  "adde")
+BU_ALTIVEC_OVERLOAD_X (ADDEC, "addec")
 BU_ALTIVEC_OVERLOAD_X (CTF,   "ctf")
 BU_ALTIVEC_OVERLOAD_X (CTS,   "cts")
 BU_ALTIVEC_OVERLOAD_X (CTU,   "ctu")
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 235962)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -4661,6 +4661,79 @@ assignment for unaligned loads and stores");
}
 }
 
+  if (fcode == ALTIVEC_BUILTIN_VEC_ADDEC)
+{
+  /* vec_addec needs to be special cased because there is no instruction
+   for the {un}signed int version.  */
+  if (nargs != 3)
+   {
+ error ("vec_addec only accepts 3 arguments");
+ return error_mark_node;
+   }
+
+  tree arg0 = (*arglist)[0];
+  tree arg0_type = TREE_TYPE (arg0);
+  tree arg1 = (*arglist)[1];
+  tree arg1_type = TREE_TYPE (arg1);
+  tree arg2 = (*arglist)[2];
+  tree arg2_type = TREE_TYPE (arg2);
+
+  /* All 3 arguments must be vectors of (signed or unsigned) (int or
+   __int128) and the types must match.  */
+  if ((arg0_type != arg1_type) || (arg1_type != arg2_type))
+   goto bad; 
+  if (TREE_CODE (arg0_type) != VECTOR_TYPE)
+   goto bad; 
+
+  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
+   {
+ /* For {un}signed ints, 
+ vec_addec (va, vb, carryv) == vec_or (vec_addc (va, vb),
+   vec_addc(vec_add(va, vb),
+vec_and (carryv, 0x1))).  */
+ case SImode:
+   {
+   /* Use save_expr to ensure that operands used more than once
+   that may have side effects (like calls) are only evaluated
+   once.  */
+   arg0 = save_expr(arg0);
+   arg1 = save_expr(arg1);
+   vec<tree, va_gc> *params = make_tree_vector();
+   vec_safe_push (params, arg0);
+   vec_safe_push (params, arg1);
+   tree call1 = altivec_resolve_overloaded_builtin
+   (loc, rs6000_builtin_decls[ALTIVEC_BUILTIN_VEC_ADDC], params);
+   params = make_tree_vector();
+   vec_safe_

Re: [PATCH, rs6000] Add support for int versions of vec_adde

2016-04-13 Thread Bill Seurer

Segher pointed out a few formatting issues via IRC which I have fixed.

On 04/13/16 09:47, Bill Seurer wrote:

Here is an updated patch:


This patch adds support for the signed and unsigned int versions of the
vec_adde altivec builtins from the Power Architecture 64-Bit ELF V2 ABI
OpenPOWER ABI for Linux Supplement (16 July 2015 Version 1.1). There are
many of the builtins that are missing and this is the first of a series
of patches to add them.

There aren't instructions for the int versions of vec_adde so the
output code is built from other built-ins that do have instructions
which in this case is just two vec_adds.

The new test cases are executable tests which verify that the generated
code produces expected values. C macros were used so that the same
test case could be used for both the signed and unsigned versions. An
extra executable test case is also included to ensure that the modified
support for the __int128 versions of vec_adde is not broken. The same
test case could not be used for both int and __int128 because of some
differences in loading and storing the vectors.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this ok for trunk?

[gcc]

2016-04-06 Bill Seurer <seu...@linux.vnet.ibm.com>

* config/rs6000/rs6000-builtin.def (vec_adde): Change vec_adde to a
special case builtin.
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Remove
ALTIVEC_BUILTIN_VEC_ADDE.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Add
support for ALTIVEC_BUILTIN_VEC_ADDE.
* config/rs6000/rs6000.c (altivec_init_builtins): Add definition
for __builtin_vec_adde.

[gcc/testsuite]

2016-04-06 Bill Seurer <seu...@linux.vnet.ibm.com>

* gcc.target/powerpc/vec-adde.c: New test.
* gcc.target/powerpc/vec-adde-int128.c: New test.


Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 234936)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -951,7 +951,6 @@ BU_ALTIVEC_X (VEC_EXT_V4SF, "vec_ext_v4sf", CO
 before we get to the point about classifying the builtin type.  */

  /* 3 argument Altivec overloaded builtins.  */
-BU_ALTIVEC_OVERLOAD_3 (ADDE,  "adde")
  BU_ALTIVEC_OVERLOAD_3 (ADDEC,"addec")
  BU_ALTIVEC_OVERLOAD_3 (MADD,   "madd")
  BU_ALTIVEC_OVERLOAD_3 (MADDS,  "madds")
@@ -1137,6 +1136,7 @@ BU_ALTIVEC_OVERLOAD_P (VCMPGT_P,   "vcmpgt_p")
  BU_ALTIVEC_OVERLOAD_P (VCMPGE_P,   "vcmpge_p")

  /* Overloaded Altivec builtins that are handled as special cases.  */
+BU_ALTIVEC_OVERLOAD_X (ADDE,  "adde")
  BU_ALTIVEC_OVERLOAD_X (CTF,  "ctf")
  BU_ALTIVEC_OVERLOAD_X (CTS,  "cts")
  BU_ALTIVEC_OVERLOAD_X (CTU,  "ctu")
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 234936)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -842,11 +842,6 @@ const struct altivec_builtin_types altivec_overloa
  RS6000_BTI_unsigned_V1TI, 0 },
{ ALTIVEC_BUILTIN_VEC_ADDC, P8V_BUILTIN_VADDCUQ,
  RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI, 0 },
-  { ALTIVEC_BUILTIN_VEC_ADDE, P8V_BUILTIN_VADDEUQM,
-RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI,
-RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI },
-  { ALTIVEC_BUILTIN_VEC_ADDE, P8V_BUILTIN_VADDEUQM,
-RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI },
{ ALTIVEC_BUILTIN_VEC_ADDEC, P8V_BUILTIN_VADDECUQ,
  RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI,
  RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI },
@@ -4515,6 +4510,62 @@ assignment for unaligned loads and stores");
  warning (OPT_Wdeprecated, "vec_lvsr is deprecated for little endian; use \
  assignment for unaligned loads and stores");

+  if (fcode == ALTIVEC_BUILTIN_VEC_ADDE)
+{
+  /* vec_adde needs to be special cased because there is no instruction
+ for the {un}signed int version.  */
+  if (nargs != 3)
+   {
+ error ("vec_adde only accepts 3 arguments");
+ return error_mark_node;
+   }
+
+  tree arg0 = (*arglist)[0];
+  tree arg0_type = TREE_TYPE (arg0);
+  tree arg1 = (*arglist)[1];
+  tree arg1_type = TREE_TYPE (arg1);
+  tree arg2 = (*arglist)[2];
+  tree arg2_type = TREE_TYPE (arg2);
+
+  /* All 3 arguments must be vectors of (signed or unsigned) (int or
+ __int128) and the types must match.  */
+  if ((arg0_type != arg1_type) || (arg1_type != arg2_type))
+   goto bad;
+  if (TREE_CODE (arg0_type) != VECTOR_TYPE)
+   goto bad;
+
+  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
+   {
+ /* For {un}signed ints,
+vec_adde (va, vb, carryv) == vec

Re: [PATCH, rs6000] Add support for int versions of vec_adde

2016-04-13 Thread Bill Seurer
Here is an updated patch:


This patch adds support for the signed and unsigned int versions of the
vec_adde altivec builtins from the Power Architecture 64-Bit ELF V2 ABI
OpenPOWER ABI for Linux Supplement (16 July 2015 Version 1.1). There are
many of the builtins that are missing and this is the first of a series
of patches to add them.

There aren't instructions for the int versions of vec_adde so the
output code is built from other built-ins that do have instructions
which in this case is just two vec_adds.

The new test cases are executable tests which verify that the generated
code produces expected values. C macros were used so that the same
test case could be used for both the signed and unsigned versions. An
extra executable test case is also included to ensure that the modified
support for the __int128 versions of vec_adde is not broken. The same
test case could not be used for both int and __int128 because of some
differences in loading and storing the vectors.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this ok for trunk?

[gcc]

2016-04-06 Bill Seurer <seu...@linux.vnet.ibm.com>

* config/rs6000/rs6000-builtin.def (vec_adde): Change vec_adde to a
special case builtin.
* config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Remove
ALTIVEC_BUILTIN_VEC_ADDE.
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Add
support for ALTIVEC_BUILTIN_VEC_ADDE.
* config/rs6000/rs6000.c (altivec_init_builtins): Add definition
for __builtin_vec_adde.

[gcc/testsuite]

2016-04-06 Bill Seurer <seu...@linux.vnet.ibm.com>

* gcc.target/powerpc/vec-adde.c: New test.
* gcc.target/powerpc/vec-adde-int128.c: New test.


Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 234936)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -951,7 +951,6 @@ BU_ALTIVEC_X (VEC_EXT_V4SF, "vec_ext_v4sf", CO
before we get to the point about classifying the builtin type.  */
 
 /* 3 argument Altivec overloaded builtins.  */
-BU_ALTIVEC_OVERLOAD_3 (ADDE,  "adde")
 BU_ALTIVEC_OVERLOAD_3 (ADDEC, "addec")
 BU_ALTIVEC_OVERLOAD_3 (MADD,   "madd")
 BU_ALTIVEC_OVERLOAD_3 (MADDS,  "madds")
@@ -1137,6 +1136,7 @@ BU_ALTIVEC_OVERLOAD_P (VCMPGT_P,   "vcmpgt_p")
 BU_ALTIVEC_OVERLOAD_P (VCMPGE_P,   "vcmpge_p")
 
 /* Overloaded Altivec builtins that are handled as special cases.  */
+BU_ALTIVEC_OVERLOAD_X (ADDE,  "adde")
 BU_ALTIVEC_OVERLOAD_X (CTF,   "ctf")
 BU_ALTIVEC_OVERLOAD_X (CTS,   "cts")
 BU_ALTIVEC_OVERLOAD_X (CTU,   "ctu")
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 234936)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -842,11 +842,6 @@ const struct altivec_builtin_types altivec_overloa
 RS6000_BTI_unsigned_V1TI, 0 },
   { ALTIVEC_BUILTIN_VEC_ADDC, P8V_BUILTIN_VADDCUQ,
 RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI, 0 },
-  { ALTIVEC_BUILTIN_VEC_ADDE, P8V_BUILTIN_VADDEUQM,
-RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI,
-RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI },
-  { ALTIVEC_BUILTIN_VEC_ADDE, P8V_BUILTIN_VADDEUQM,
-RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI },
   { ALTIVEC_BUILTIN_VEC_ADDEC, P8V_BUILTIN_VADDECUQ,
 RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI,
 RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI },
@@ -4515,6 +4510,62 @@ assignment for unaligned loads and stores");
 warning (OPT_Wdeprecated, "vec_lvsr is deprecated for little endian; use \
 assignment for unaligned loads and stores");
 
+  if (fcode == ALTIVEC_BUILTIN_VEC_ADDE)
+{
+  /* vec_adde needs to be special cased because there is no instruction
+ for the {un}signed int version.  */
+  if (nargs != 3)
+   {
+ error ("vec_adde only accepts 3 arguments");
+ return error_mark_node;
+   }
+
+  tree arg0 = (*arglist)[0];
+  tree arg0_type = TREE_TYPE (arg0);
+  tree arg1 = (*arglist)[1];
+  tree arg1_type = TREE_TYPE (arg1);
+  tree arg2 = (*arglist)[2];
+  tree arg2_type = TREE_TYPE (arg2);
+
+  /* All 3 arguments must be vectors of (signed or unsigned) (int or
+ __int128) and the types must match.  */
+  if ((arg0_type != arg1_type) || (arg1_type != arg2_type))
+   goto bad; 
+  if (TREE_CODE (arg0_type) != VECTOR_TYPE)
+   goto bad; 
+
+  switch (TYPE_MODE (TREE_TYPE (arg0_type)))
+   {
+ /* For {un}signed ints, 
+vec_adde (va, vb, carryv) == vec_add (vec_add (va, vb), vec_and 
(carryv, 0x1)).  */
+ case SImode:
+   {
+ vec<tree

Re: [PATCH, rs6000] Add support for int versions of vec_adde

2016-04-08 Thread Bill Seurer

On 04/08/16 09:50, Segher Boessenkool wrote:

Hi Bill,

On Thu, Apr 07, 2016 at 04:04:30PM -0500, Bill Seurer wrote:

On 04/05/16 21:27, David Edelsohn wrote:

On Tue, Apr 5, 2016 at 3:36 PM, Bill Seurer <seu...@linux.vnet.ibm.com>

 * config/rs6000/rs6000-c.c (altivec_overloaded_builtins,
 altivec_resolve_overloaded_builtin): Remove
 ALTIVEC_BUILTIN_VEC_ADDE
 from altivec_overloaded_builtins structure.  Add support for it
 to
 altivec_resolve_overloaded_builtin function.


A total nit, but...  If you change one thing in one places, and another
in another, put them in the changelog separately.


OK.


+ /* for {un}signed ints,
+vec_adde (va, vb, carryv) == vec_add (vec_add (va, vb),
carryv) */


Same.


Also sentences start with a capital letter.

What is the definition of the builtin?  The machine insn does
va + vb + (carryv & 1); your implementation skips the AND.


From the ABI document:
Purpose:
Returns a vector containing the result of adding each set of the 
corresponding elements of ARG1 and ARG2 with a carry (that has a value 
of either 0 or 1) specified as the ARG3 vector.

Result value:
The value of each element of the result is produced by adding the 
corresponding elements of ARG1 and ARG2 and a carry specified in ARG3 (1 
if there is a carry, 0 otherwise).



It's not really clear what should be done if the carry is not 1 or 0 
from that description because it specifies that the carry IS 1 or 0.


I tried it and the instruction (for __int128's only) does indeed do the 
and which means it will add a 0 if the "carry" is something like 2.  I 
will change the test case to include "bad" values.


I can add an and easily enough.


--- gcc/testsuite/gcc.target/powerpc/vec-adde-int128.c  (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/vec-adde-int128.c  (working copy)
@@ -0,0 +1,78 @@
+/* { dg-do run { target { powerpc64le-*-* } } } */


Will powerpc64 (i.e. BE) not work?


No, it does work.  The other test cases I was using as models only 
targeted LE (though on inspection most if not all of them would also 
work on BE).  I suppose there's no reason to do that here, though.

--

-Bill Seurer



Re: [PATCH, rs6000] Add support for int versions of vec_adde

2016-04-07 Thread Bill Seurer

On 04/05/16 21:27, David Edelsohn wrote:

On Tue, Apr 5, 2016 at 3:36 PM, Bill Seurer <seu...@linux.vnet.ibm.com> wrote:

This patch adds support for the signed and unsigned int versions of the
vec_adde altivec builtins from the Power Architecture 64-Bit ELF V2 ABI
OpenPOWER ABI for Linux Supplement (16 July 2015 Version 1.1).  There are
many of the builtins that are missing and this is the first of a series
of patches to add them.

There aren't instructions for the int versions of vec_adde so the
output code is built from other built-ins that do have instructions
which in this case is just two vec_adds.

The new test cases are executable tests which verify that the generated
code produces expected values.  C macros were used so that the same
test case could be used for both the signed and unsigned versions.  An
extra executable test case is also included to ensure that the modified
support for the __int128 versions of vec_adde is not broken.  The same
test case could not be used for both int and __int128 because of some
differences in loading and storing the vectors.

Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions.  Is this ok for trunk?

[gcc]

2016-04-06  Bill Seurer  <seu...@linux.vnet.ibm.com>

 * config/rs6000/rs6000-builtin.def (vec_adde): Change vec_adde to a
 special case builtin.
 * config/rs6000/rs6000-c.c (altivec_overloaded_builtins,
 altivec_resolve_overloaded_builtin): Remove ALTIVEC_BUILTIN_VEC_ADDE
 from altivec_overloaded_builtins structure.  Add support for it to
 altivec_resolve_overloaded_builtin function.
 * config/rs6000/rs6000.c (altivec_init_builtins): Add definition
 for __builtin_vec_adde.

[gcc/testsuite]

2016-04-06  Bill Seurer  <seu...@linux.vnet.ibm.com>

 * gcc.target/powerpc/vec-adde.c: New test.
 * gcc.target/powerpc/vec-adde-int128.c: New test.

Index: gcc/config/rs6000/rs6000-builtin.def
===
--- gcc/config/rs6000/rs6000-builtin.def(revision 234745)
+++ gcc/config/rs6000/rs6000-builtin.def(working copy)
@@ -951,7 +951,6 @@ BU_ALTIVEC_X (VEC_EXT_V4SF, "vec_ext_v4sf", CO
 before we get to the point about classifying the builtin type.  */

  /* 3 argument Altivec overloaded builtins.  */
-BU_ALTIVEC_OVERLOAD_3 (ADDE,  "adde")
  BU_ALTIVEC_OVERLOAD_3 (ADDEC, "addec")
  BU_ALTIVEC_OVERLOAD_3 (MADD,   "madd")
  BU_ALTIVEC_OVERLOAD_3 (MADDS,  "madds")
@@ -1137,6 +1136,7 @@ BU_ALTIVEC_OVERLOAD_P (VCMPGT_P,   "vcmpgt_p")
  BU_ALTIVEC_OVERLOAD_P (VCMPGE_P,   "vcmpge_p")

  /* Overloaded Altivec builtins that are handled as special cases.  */
+BU_ALTIVEC_OVERLOAD_X (ADDE,  "adde")
  BU_ALTIVEC_OVERLOAD_X (CTF,   "ctf")
  BU_ALTIVEC_OVERLOAD_X (CTS,   "cts")
  BU_ALTIVEC_OVERLOAD_X (CTU,   "ctu")
Index: gcc/config/rs6000/rs6000-c.c
===
--- gcc/config/rs6000/rs6000-c.c(revision 234745)
+++ gcc/config/rs6000/rs6000-c.c(working copy)
@@ -842,11 +842,6 @@ const struct altivec_builtin_types altivec_overloa
  RS6000_BTI_unsigned_V1TI, 0 },
{ ALTIVEC_BUILTIN_VEC_ADDC, P8V_BUILTIN_VADDCUQ,
  RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI, 0 },
-  { ALTIVEC_BUILTIN_VEC_ADDE, P8V_BUILTIN_VADDEUQM,
-RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI,
-RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI },
-  { ALTIVEC_BUILTIN_VEC_ADDE, P8V_BUILTIN_VADDEUQM,
-RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI, RS6000_BTI_V1TI },
{ ALTIVEC_BUILTIN_VEC_ADDEC, P8V_BUILTIN_VADDECUQ,
  RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI,
  RS6000_BTI_unsigned_V1TI, RS6000_BTI_unsigned_V1TI },
@@ -4515,6 +4510,59 @@ assignment for unaligned loads and stores");
  warning (OPT_Wdeprecated, "vec_lvsr is deprecated for little endian; use \
  assignment for unaligned loads and stores");

+  if (fcode == ALTIVEC_BUILTIN_VEC_ADDE)
+{
+  /* vec_adde needs to be special cased because there is no instruction
+ for the {un}signed int version */


End comment sentence with period and two spaces


+  if (nargs != 3)
+   {
+ error ("vec_adde only accepts 3 arguments");
+ return error_mark_node;
+   }
+
+  tree arg0 = (*arglist)[0];
+  tree arg0_type = TREE_TYPE (arg0);
+  tree arg1 = (*arglist)[1];
+  tree arg1_type = TREE_TYPE (arg1);
+  tree arg2 = (*arglist)[2];
+  tree arg2_type = TREE_TYPE (arg2);
+
+  /* All 3 arguments must be vectors of (signed or unsigned) (int or
+ __int128) and the types must match */


Same.


+  if ((arg0_type != arg1_type) || (arg1_type != arg2_type))
+   goto bad;
+  if (TREE_CODE (arg0_type) !=

[COMMITTED] Add myself as GCC maintainer

2016-04-04 Thread Bill Seurer
I've added myself to the "Write After Approval" maintainers (Committed revision 
234724):

Index: ChangeLog
===
--- ChangeLog   (revision 234723)
+++ ChangeLog   (working copy)
@@ -1,3 +1,7 @@
+2016-04-04  Bill Seurer  <seu...@linux.vnet.ibm.com>
+
+   * MAINTAINERS (Write After Approval): Add myself.
+
 2016-03-29  Kelvin Nilsen  <kdnil...@linux.vnet.ibm.com>
 
* MAINTAINERS (Write After Approval): Add myself.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 234723)
+++ MAINTAINERS (working copy)
@@ -566,6 +566,7 @@ Martin Sebor
<mse...@gcc.gnu.org>
 Dodji Seketeli <do...@gcc.gnu.org>
 Svein Seldal   <sv...@dev.seldal.com>
 Thiemo Seufer      <t...@networkno.de>
+Bill Seurer<seu...@linux.vnet.ibm.com>
 Marcus Shawcroft   <marcus.shawcr...@arm.com>
 Tim Shen   <tims...@google.com>
 David Sherwood     <david.sherw...@arm.com>
-- 

-Bill Seurer