More PPro bugs in egcs

More PPro bugs in egcs

[H.J. Lu]

Hi,

This is another PPro bug.

# cc -S -O2 -march=i686 -B/home/work/gnu/bin/egcs/gcc/ -dra c_cos.c
cc: Internal compiler error: program cc1 got fatal signal 6

Thanks.


-- 
H.J. Lu (hjl@gnu.org)
----c_cos.c---
typedef double real;
typedef struct { real r, i; } complex;
extern __inline    double        sin    (  double   __x)
{
  register   double   __result;
  __asm __volatile__ (      "fsin"    : "=t" (__result) :   "0" (__x) );
  return __result;
}
extern __inline    double    __sgn1l  (  double    __x )
{
  return __x >= 0.0 ? 1.0 : -1.0;
}
extern __inline   double     sinh   ( double      __x  )
{
  return __x * __sgn1l (__x);
}
void c_cos(complex *resx, complex *z)
{
resx->i = - sin(z->r) * sinh(z->i);
}

Re: More PPro bugs in egcs

[Jim Wilson]

The problem here is that the x86 port uses cc0, and the conditional move
instructions use cc0.  Since we can't put instructions between a cc0
setter/user pair, this means that the conditional move instruction can't
have input reloads, which means that it must be able to handle any valid
operand.  I see now why it tried to handle CONST_DOUBLE, but it was handling
them the wrong way because it was trying to use CONST_DOUBLE_MEM.

Also, I see now why you said the CONST_DOUBLE_MEM stuff wasn't your fault.
This stuff was there before your patch.  Your patch just moved it around a
little and I mistakenly thought you were adding those lines.  Sorry about that.

So the x86 conditional move instructions still need a lot more work.  Here are
three possible ways to fix the problem:
1) Modify LEGITIMATE_CONSTANT_P to only accept those FP constants that can
   easily be handled in the FP conditional move instructions.  E.g.
	#define LEGITIMATE_CONSTANT_P(X)   \
	  (GET_CODE (X) != CONST_DOUBLE                                \
	   || (TARGET_80387 && standard_80387_constant_p (X)))
   and then add H.J.Lu's patch to handle 0.0 and 1.0.
2) Modify the FP conditional move instructions to properly handle all
   constants.  This means adding code to load the constants directly without
   using CONST_DOUBLE_MEM.  This could be done for 0.0 and 1.0 via H.J.Lu's
   patch.  For other constants we need to use output_move_const_single or
   output_move_double or similar routines.  However, we need to make sure
   that those routines will not use instructions that modify the condition
   codes when loading a CONST_DOUBLE.  That might be a maintenance problem.
3) Modify the FP conditional move patterns to include the compare operation.
   This would allow them to have input reloads, and these problems with
   constants go away.  You could then have a define_split whose condition
   tests reload_completed to turn these combo instructions into separate
   compare and cmove instructions after reload.

Stan, is this something you can work on?

Jim