SPARC: fix gcc.dg/ultrasp11.c

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

The test fails at -O -mcpu=v9 in 32-bit mode with the GNU binutils because

(mem/u/f:TF (lo_sum:SI (reg/f:SI 1 %g1 [111])
        (symbol_ref/u:SI ("*.LLC0") [flags 0x2])) [0 S16 A64])

is not recognized as an offsettable memory reference: the address

(plus:SI (lo_sum:SI (reg/f:SI 1 %g1 [111])
        (symbol_ref/u:SI ("*.LLC0") [flags 0x2]))
  (const_int 15))

is correctly rejected by legitimate_address_p.


The testcase was added under PR target/17245, which was the same bug reported 
with the Sun binutils instead of the GNU binutils.  The fix I installed

@@ -3557,10 +3540,25 @@
       if (! CONSTANT_P (imm1) || tls_symbolic_operand (rs1))
        return 0;

-      /* We can't allow TFmode, because an offset greater than or equal to 
the
-         alignment (8) may cause the LO_SUM to overflow if !v9.  */
-      if (mode == TFmode && !TARGET_V9)
-       return 0;
+      if (USE_AS_OFFSETABLE_LO10)
+       {
+         /* We can't allow TFmode, because an offset greater than or equal to
+            the alignment (8) may cause the LO_SUM to overflow if !v9.  */
+         if (mode == TFmode && ! TARGET_V9)
+           return 0;
+       }
+      else
+        {
+         /* We prohibit LO_SUM for TFmode when there are no quad move insns
+            and we consequently need to split.  We do this because LO_SUM
+            is not an offsettable address.  If we get the situation in reload
+            where source and destination of a movtf pattern are both MEMs 
with
+            LO_SUM address, then only one of them gets converted to an
+            offsettable address.  */
+         if (mode == TFmode
+             && ! (TARGET_FPU && TARGET_ARCH64 && TARGET_HARD_QUAD))
+           return 0;
+       }
     }
   else if (GET_CODE (addr) == CONST_INT && SMALL_INT (addr))
     return 1;

turns out to have partially addressed only the symptoms and not the very cause 
of the problem: TFmode memory references containing a LO_SUM are not 
offsettable in 32-bit mode because they are only 64-bit aligned as per the 
ABI.  So the condition should test TARGET_64BIT and not only TARGET_V9:

     /* We can't allow TFmode in 32-bit mode, because an offset greater
	than the alignment (8) may cause the LO_SUM to overflow.  */
     if (mode == TFmode && !TARGET_64BIT)
	return 0;

Tested on sparc-sun-solaris2.7, applied to mainline, 4.0 and 3.4 branch.


2005-04-06  Eric Botcazou  <ebotcazou@libertysurf.fr>

	PR target/17245
	* config/sparc/sparc.c (legitimate_address_p): Remove 'imm2'.
	Revert 2004-10-08 patch.  Reject TFmode LO_SUM in 32-bit mode.


-- 
Eric Botcazou

Index: config/sparc/sparc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/sparc/sparc.c,v
retrieving revision 1.271.4.23
diff -u -p -r1.271.4.23 sparc.c
--- config/sparc/sparc.c	10 Nov 2004 17:28:55 -0000	1.271.4.23
+++ config/sparc/sparc.c	6 Apr 2005 09:51:28 -0000
@@ -3320,7 +3320,7 @@ legitimate_pic_operand_p (rtx x)
 int
 legitimate_address_p (enum machine_mode mode, rtx addr, int strict)
 {
-  rtx rs1 = NULL, rs2 = NULL, imm1 = NULL, imm2;
+  rtx rs1 = NULL, rs2 = NULL, imm1 = NULL;
 
   if (REG_P (addr) || GET_CODE (addr) == SUBREG)
     rs1 = addr;
@@ -3384,7 +3384,6 @@ legitimate_address_p (enum machine_mode 
 	       && ! TARGET_CM_MEDMID
 	       && RTX_OK_FOR_OLO10_P (rs2))
 	{
-	  imm2 = rs2;
 	  rs2 = NULL;
 	  imm1 = XEXP (rs1, 1);
 	  rs1 = XEXP (rs1, 0);
@@ -3400,25 +3399,10 @@ legitimate_address_p (enum machine_mode 
       if (! CONSTANT_P (imm1) || tls_symbolic_operand (rs1))
 	return 0;
 
-      if (USE_AS_OFFSETABLE_LO10)
-	{
-	  /* We can't allow TFmode, because an offset greater than or equal to
-	     the alignment (8) may cause the LO_SUM to overflow if !v9.  */
-	  if (mode == TFmode && ! TARGET_V9)
-	    return 0;
-	}
-      else
-        {
-	  /* We prohibit LO_SUM for TFmode when there are no quad move insns
-	     and we consequently need to split.  We do this because LO_SUM
-	     is not an offsettable address.  If we get the situation in reload
-	     where source and destination of a movtf pattern are both MEMs with
-	     LO_SUM address, then only one of them gets converted to an
-	     offsettable address.  */
-	  if (mode == TFmode
-	      && ! (TARGET_FPU && TARGET_ARCH64 && TARGET_HARD_QUAD))
-	    return 0;
-	}
+      /* We can't allow TFmode in 32-bit mode, because an offset greater
+	 than the alignment (8) may cause the LO_SUM to overflow.  */
+      if (mode == TFmode && !TARGET_64BIT)
+	return 0;
     }
   else if (GET_CODE (addr) == CONST_INT && SMALL_INT (addr))
     return 1;