This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

ppc patch



Compile this with -O2 -msoft-float on a powerpc target to make
the compiler abort (I've tried powerpc-elf and powerpc-ibm-aix4.1).
This is happening in the mainline sources, not on the branch.

typedef int __int32_t;
int __kernel_rem_pio2(int prec)
{
	__int32_t i, jz;
	double fw, fq[20];
	switch(prec) {
	    case 2:
		fw = 0.0;
	    case 3:	 
		for (i=jz;i>0;i--) {
		    fw      = fq[i-1] +fq[i]; 
		    fq[i-1] = fw;
		}
	}
}


j.c: In function `__kernel_rem_pio2':
j.c:15: internal error--insn does not satisfy its constraints:
(insn 160 67 23 (set (mem/s:DF (pre_dec:SI (reg:SI 31 r31)))
        (reg:DF 3 r3)) 421 {*movdf_softfloat32} (nil)
    (nil))


The problem (as best as I can tell) is the constraints on this insn:

(define_insn "*movdf_softfloat32"
  [(set (match_operand:DF 0 "nonimmediate_operand" "=r,r,o,r,r,r")
        (match_operand:DF 1 "input_operand" "r,o,r,G,H,F"))]
  "! TARGET_POWERPC64 && TARGET_SOFT_FLOAT
   && (register_operand (operands[0], DFmode)
       || register_operand (operands[1], DFmode))"


Note that we have 'o' for an offsettable memory address.  However,
autoincrement memory addresses are not offsettable.

You might think that reload would clean this up for us.  It does not
because according to GO_IF_LEGITIMATE_ADDRESS the address is valid
(see reload.c::find_reloads_address).

With no other memory alternatives reload aborts as there's no way to
this insn.

Luckily I believe the fix is simple.  All I think we need to do is
change 'o' above to 'm' in both occurrences.  This should be safe
unless there is some reason why we need to be avoiding autoinc addresses
for DFmode memory accesses when TARGET_SOFT_FLOAT is enabled.

Further evidence that this is the right fix can be found in the movdi
insn, which uses 'm' and generates _identical_ code for the two alternatives
we care about.



The egcs-1.1 branch does not exhibit this behavior, but I believe that
is by accident, not by design.  rth's loop patches just happen to expose
some new autoincrement opportunities, which then exposed this latent
bug.


With your approval I'd like to install this change.  There were
a couple other fishy uses of 'o', but I don't know the ppc well
enough to know if they were problems or not.


	* rs6000.md (movdf_softfloat32): Accept any valid memory
	address.

Index: config/rs6000/rs6000.md
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/./gcc/config/rs6000/rs6000.md,v
retrieving revision 1.26
diff -c -3 -p -r1.26 rs6000.md
*** rs6000.md	1998/08/20 10:50:39	1.26
--- rs6000.md	1998/08/22 06:10:14
***************
*** 5995,6002 ****
     (set_attr "length" "8,8,8,8,12,16,*,*,*")])
  
  (define_insn "*movdf_softfloat32"
!   [(set (match_operand:DF 0 "nonimmediate_operand" "=r,r,o,r,r,r")
! 	(match_operand:DF 1 "input_operand" "r,o,r,G,H,F"))]
    "! TARGET_POWERPC64 && TARGET_SOFT_FLOAT
     && (register_operand (operands[0], DFmode)
         || register_operand (operands[1], DFmode))"
--- 5995,6002 ----
     (set_attr "length" "8,8,8,8,12,16,*,*,*")])
  
  (define_insn "*movdf_softfloat32"
!   [(set (match_operand:DF 0 "nonimmediate_operand" "=r,r,m,r,r,r")
! 	(match_operand:DF 1 "input_operand" "r,m,r,G,H,F"))]
    "! TARGET_POWERPC64 && TARGET_SOFT_FLOAT
     && (register_operand (operands[0], DFmode)
         || register_operand (operands[1], DFmode))"










Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]