[PATCH] testsuite: All LRA target selector

2021-03-09 Thread Dave Anglin
Okay?

Add LRA target selector.

gcc/testsuite/ChangeLog:

PR testsuite/99292
* lib/target-supports.exp (check_effective_target_lra): New.
* gcc.c-torture/compile/asmgoto-2.c: Use LRA target selector.
* gcc.c-torture/compile/asmgoto-5.c: Likewise.
* gcc.c-torture/compile/pr98096.c: Likewise.
* gcc.dg/pr97954.c: Likewise.

diff --git a/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c 
b/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c
index d2d2ac536bd..43e597bc59f 100644
--- a/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c
+++ b/gcc/testsuite/gcc.c-torture/compile/asmgoto-2.c
@@ -1,6 +1,5 @@
 /* This test should be switched off for a new target with less than 4 
allocatable registers */
-/* { dg-do compile } */
-/* { dg-skip-if "Reload target" { hppa*-*-* } } */
+/* { dg-do compile { target lra } } */
 int
 foo (void)
 {
diff --git a/gcc/testsuite/gcc.c-torture/compile/asmgoto-5.c 
b/gcc/testsuite/gcc.c-torture/compile/asmgoto-5.c
index ce751ced90c..e1574a2903a 100644
--- a/gcc/testsuite/gcc.c-torture/compile/asmgoto-5.c
+++ b/gcc/testsuite/gcc.c-torture/compile/asmgoto-5.c
@@ -1,7 +1,6 @@
 /* Test to generate output reload in asm goto on x86_64.  */
-/* { dg-do compile } */
+/* { dg-do compile { target lra } } */
 /* { dg-skip-if "no O0" { { i?86-*-* x86_64-*-* } && { ! ia32 } } { "-O0" } { 
"" } } */
-/* { dg-skip-if "Reload target" { hppa*-*-* } } */

 #if defined __x86_64__
 #define ASM(s) asm (s)
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr98096.c 
b/gcc/testsuite/gcc.c-torture/compile/pr98096.c
index 95ad55c81aa..bba3fa5c619 100644
--- a/gcc/testsuite/gcc.c-torture/compile/pr98096.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr98096.c
@@ -1,6 +1,6 @@
 /* Test for correct naming of label operands in asm goto in case of presence of
input/output operands. */
-/* { dg-do compile } */
+/* { dg-do compile { target lra } } */
 int i, j;
 int f(void) {
   asm goto ("# %0 %2" : "+r" (i) ::: jmp);
diff --git a/gcc/testsuite/gcc.dg/pr97954.c b/gcc/testsuite/gcc.dg/pr97954.c
index 178e1d2e965..0be60f500b6 100644
--- a/gcc/testsuite/gcc.dg/pr97954.c
+++ b/gcc/testsuite/gcc.dg/pr97954.c
@@ -1,5 +1,5 @@
 /* PR rtl-optimization/97954 */
-/* { dg-do compile } */
+/* { dg-do compile { target lra } } */
 /* { dg-options "-O2" } */

 int
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index 570d5d3de00..7d50ee94ecf 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -10990,3 +10990,13 @@ proc check_effective_target_o_flag_in_section { } {
}
 }]
 }
+
+# return 1 if LRA is supported.
+
+proc check_effective_target_lra { } {
+if { [istarget hppa*-*-*] } {
+   return 0
+}
+return 1
+}
+


Re: [wwwdocs] Update list of 4.9 secondary platforms

2014-03-22 Thread Dave Anglin
On Thu, Mar 13, 2014 at 09:06:43AM -0600, Jeff Law wrote:
 On 03/13/14 09:02, Jakub Jelinek wrote:
 Hi!
 
 I've been told that the SC has approved the secondary platform list changes,
 so I went ahead and committed the changes to our web pages.
 Thanks.  I should have taken care of this a few weeks ago when the decision
 was made.
 
 Hopefully everyone realizes that the committee is just dropping an
 effectively dead platform and adding a more vibrant platform in the
 secondary platform list.

Of course I'm biased but I would have replaced hppa2.0w-hp-hpux11.11
with hppa-unknown-linux-gnu.  See for example:
http://buildd.debian-ports.org/stats/

I also note that alpha is still strong in spite of the fact that it's
also effectively dead.




Re: [PATCH] Fix PR middle-end/52894

2012-04-10 Thread Dave Anglin

On 10-Apr-12, at 7:06 AM, Richard Guenther wrote:

I can't immediately see how your description of the list of pending  
externals
and the vector is deleted.  pa.c keeps its own vector which  
references the
decls and the only issue I see is that if you call assemble_external  
after
processing externals you ICE because the pointer-set is not  
initialized?


Why does the pa backend end up calling assemble_external at final  
time?


The backend calls assemble_integer to output function descriptors at  
final

time.  This indirectly calls assemble_external from output_addr_const.
This can be seen in comment #4 in the PR.  This occurs after the pending
externals are processed.

We have to ensure that we only output function descriptors that are  
referenced,

and we can only determine this at final.

As a result, assemble_external is called after the VEC has been deleted.
The compiler doesn't ICE.  It goes into an infinite loop when a call to
pointer_set_insert tries to extend the deleted VEC.  It does this even  
if the

pointer is already in the VEC hash.

Previously, the storage wasn't deleted.  I suspect the ineffective  
calls on hpux
weren't noticed because assemble_external had already been called for  
the

function descriptors earlier, so the list in the backend was complete.

The problem was first seen with the Linux target.  There is no backend
list for this target because it doesn't use or need assemble_external.

I personally think it was wrong to add the deferral in  
assemble_external,

but that's another issue.

Dave.