From: Steven Bosscher <s.bosscher@student.tudelft.nl>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, adconrad@0c3.net,
	nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, 186299@bugs.debian.org
Cc:  
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn,
 at recog.c:2175
Date: Mon, 07 Apr 2003 09:12:21 +0200

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10315
 
 Is this problem present on mainline as well?
 

From: Geoffrey Keating <geoffk@apple.com>
To: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, adconrad@0c3.net,
   nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, 186299@bugs.debian.org
Cc:  
Subject: Re: optimization/10315: [3.2/3.3/3.4 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Tue, 22 Apr 2003 16:52:14 -0700

 I'm not sure why this insn isn't being recognised, it should be a 
 'movdf_hardfloat32'.
 It's a valid machine instruction if pseudo-register 311 happens to be 
 allocated to a pair of integer registers.
 -- 
 Geoff Keating <geoffk@apple.com>
 

From: David Edelsohn <dje@watson.ibm.com>
To: Geoff Keating <geoffk@geoffk.org>
Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>, gcc-gnats@gcc.gnu.org,
   gcc-bugs@gcc.gnu.org, adconrad@0c3.net, 186299@bugs.debian.org
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in	extract_insn, at recog.c:2175
Date: Tue, 22 Apr 2003 23:14:37 -0400

 	The problem is easy_fp_constant():
 
   /* If we are using V.4 style PIC, consider all constants to be hard.  */
   if (flag_pic && DEFAULT_ABI == ABI_V4)
     return 0;
 
 This means that "input_operand" predicate fails for movdf_hardfloat32 when
 presented with const_double:DF.  I'm not sure what's suppose to save us at
 that point.
 
 David

From: Geoff Keating <geoffk@geoffk.org>
To: dje@watson.ibm.com
Cc: s.bosscher@student.tudelft.nl, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   adconrad@0c3.net, 186299@bugs.debian.org
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in	extract_insn, at recog.c:2175
Date: Wed, 23 Apr 2003 11:14:26 -0700

 > Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>, gcc-gnats@gcc.gnu.org,
 >    gcc-bugs@gcc.gnu.org, adconrad@0c3.net, 186299@bugs.debian.org
 > Date: Tue, 22 Apr 2003 23:14:37 -0400
 > From: David Edelsohn <dje@watson.ibm.com>
 > X-OriginalArrivalTime: 23 Apr 2003 03:14:43.0793 (UTC) FILETIME=[7C849410:01C30946]
 > 
 > 	The problem is easy_fp_constant():
 > 
 >   /* If we are using V.4 style PIC, consider all constants to be hard.  */
 >   if (flag_pic && DEFAULT_ABI == ABI_V4)
 >     return 0;
 > 
 > This means that "input_operand" predicate fails for movdf_hardfloat32 when
 > presented with const_double:DF.  I'm not sure what's suppose to save us at
 > that point.
 
 In that case, the RTL should never have been generated...
 
 -- 
 - Geoffrey Keating <geoffk@geoffk.org>

From: Richard Henderson <rth@redhat.com>
To: David Edelsohn <dje@watson.ibm.com>
Cc: Geoff Keating <geoffk@geoffk.org>, s.bosscher@student.tudelft.nl,
   gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, adconrad@0c3.net,
   186299@bugs.debian.org, gcc-patches@gcc.gnu.org
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Wed, 23 Apr 2003 15:50:43 -0700

 On Wed, Apr 23, 2003 at 04:09:59PM -0400, David Edelsohn wrote:
 > 	GCC probably should not fall on its face when presented with this
 > type of error, but I am not sure who sure ensure a valid insn.
 > gen_move_insn() should not be called that late?
 
 This is the same as PR8300, which I am looking at today.
 
 
 r~

From: David Edelsohn <dje@watson.ibm.com>
To: Geoff Keating <geoffk@geoffk.org>
Cc: s.bosscher@student.tudelft.nl, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   adconrad@0c3.net, 186299@bugs.debian.org, gcc-patches@gcc.gnu.org
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175 
Date: Wed, 23 Apr 2003 16:09:59 -0400

 >>>>> Geoff Keating writes:
 
 > In that case, the RTL should never have been generated...
 
 	The original C code appears to be buggy and GCC is not handling
 the error very gracefully.  The C code is:
 
 case 'f': {
         float v;
 
         memcpy(&v, &input[inputpos], sizeof(float));
         add_assoc_double(return_value, n, (double)v);
 
         break;
 }
 
 case 'd': {
         double v;
 
         memcpy(&v, &input[inputpos], sizeof(float));
         add_assoc_double(return_value, n, v);
 
         break;
 }
 
 Notice case 'd' memcpy uses sizeof(float), not sizeof(double).  GCC
 inlines the memcpy(), but only half of "v" is set.
 flow.c:initialize_uninitialized_subregs() simply jams in a zero in the
 entry block for the function:
 
         insn = gen_move_insn (param.retval,
                               CONST0_RTX (GET_MODE (param.retval)));
 
 	If I change sizeof(float) to sizeof(double) for case 'd', the
 function compiles without error.  The sizeof(float) seems to be a typo, so
 my first suggestion is fix the source code.
 
 	GCC probably should not fall on its face when presented with this
 type of error, but I am not sure who sure ensure a valid insn.
 gen_move_insn() should not be called that late?
 
 David

From: Richard Henderson <rth@redhat.com>
To: David Edelsohn <dje@watson.ibm.com>, Geoff Keating <geoffk@geoffk.org>,
   s.bosscher@student.tudelft.nl, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   adconrad@0c3.net, 186299@bugs.debian.org, gcc-patches@gcc.gnu.org
Cc:  
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175
Date: Wed, 23 Apr 2003 21:51:18 -0700

 On Wed, Apr 23, 2003 at 03:50:43PM -0700, Richard Henderson wrote:
 > This is the same as PR8300, which I am looking at today.
 
 Well, not quite the same.  There are a couple of bugs here, any one
 of which will fix the crash.
 
 First, rs6000_emit_move decided that any time it was called with a
 non-general_operand input, that it must be reload doing something
 weird.  The attached patch (which has only been cross-tested vs the
 pr test case) would appear to do the right thing.  Would someone 
 please give this proper bootstrap testing?
 
 Second, gen_move_insn doesn't have nearly the sort of checks
 performed by emit_move_insn.  This is certainly a bug.  IMO
 gen_move_insn should be implemented as
 
 	rtx gen_move_insn (dst, src)
 	{
 	  start_sequence ();
 	  emit_move_insn (dst, src);
 	  ret = get_insns ();
 	  end_sequence ();
 	  return ret;
 	}
 
 However, I'm sure this will break something, though I don't
 know what.  Certainly we should explore something like this
 for mainline, but ...
 
 
 r~
 
 
 
 	* config/rs6000/rs6000.c (rs6000_emit_move): Only elide proper
 	checks during reload; use validize_mem instead of adjust_address.
 
 Index: config/rs6000/rs6000.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v
 retrieving revision 1.403.2.6
 diff -c -p -d -r1.403.2.6 rs6000.c
 *** config/rs6000/rs6000.c	1 Apr 2003 10:14:13 -0000	1.403.2.6
 --- config/rs6000/rs6000.c	24 Apr 2003 04:42:11 -0000
 *************** rs6000_emit_move (dest, source, mode)
 *** 2640,2655 ****
   	}
       }
   
 !   /* Handle the case where reload calls us with an invalid address;
 !      and the case of CONSTANT_P_RTX.  */
 !   if (!ALTIVEC_VECTOR_MODE (mode)
         && (! general_operand (operands[1], mode)
 ! 	  || ! nonimmediate_operand (operands[0], mode)
 ! 	  || GET_CODE (operands[1]) == CONSTANT_P_RTX))
 !     {
 !       emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
 !       return;
 !     }
     
     /* FIXME:  In the long term, this switch statement should go away
        and be replaced by a sequence of tests based on things like
 --- 2640,2654 ----
   	}
       }
   
 !   /* Handle the case where reload calls us with an invalid address.  */
 !   if (reload_in_progress && mode == Pmode
         && (! general_operand (operands[1], mode)
 ! 	  || ! nonimmediate_operand (operands[0], mode)))
 !     goto emit_set;
 ! 
 !   /* Handle the case of CONSTANT_P_RTX.  */
 !   if (GET_CODE (operands[1]) == CONSTANT_P_RTX)
 !     goto emit_set;
     
     /* FIXME:  In the long term, this switch statement should go away
        and be replaced by a sequence of tests based on things like
 *************** rs6000_emit_move (dest, source, mode)
 *** 2864,2876 ****
     /* Above, we may have called force_const_mem which may have returned
        an invalid address.  If we can, fix this up; otherwise, reload will
        have to deal with it.  */
 !   if (GET_CODE (operands[1]) == MEM
 !       && ! memory_address_p (mode, XEXP (operands[1], 0))
 !       && ! reload_in_progress)
 !     operands[1] = adjust_address (operands[1], mode, 0);
   
     emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
 -   return;
   }
   
   /* Initialize a variable CUM of type CUMULATIVE_ARGS
 --- 2863,2873 ----
     /* Above, we may have called force_const_mem which may have returned
        an invalid address.  If we can, fix this up; otherwise, reload will
        have to deal with it.  */
 !   if (GET_CODE (operands[1]) == MEM && ! reload_in_progress)
 !     operands[1] = validize_mem (operands[1]);
   
 +  emit_set:
     emit_insn (gen_rtx_SET (VOIDmode, operands[0], operands[1]));
   }
   
   /* Initialize a variable CUM of type CUMULATIVE_ARGS

From: David Edelsohn <dje@watson.ibm.com>
To: Richard Henderson <rth@redhat.com>, Geoff Keating <geoffk@geoffk.org>,
   s.bosscher@student.tudelft.nl, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
   adconrad@0c3.net, 186299@bugs.debian.org, gcc-patches@gcc.gnu.org
Cc:  
Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175 
Date: Fri, 25 Apr 2003 09:57:14 -0400

 >>>>> Richard Henderson writes:
 
 > The attached patch (which has only been cross-tested vs the
 > pr test case) would appear to do the right thing.  Would someone 
 > please give this proper bootstrap testing?
 
 	This patch bootstraps and does not introduce any new regressions
 on AIX.  Looks good to me.
 
 Thanks, David

State-Changed-From-To: open->closed
State-Changed-Why: http://gcc.gnu.org/ml/gcc-patches/2003-04/msg01849.html