[ Reported to the Debian BTS as report #186299. Please CC 186299@bugs.debian.org on replies. Log of report can be found at http://bugs.debian.org/186299 ] Rechecked with 3.2 20030314 and 3.3 20030404. While building php3 on unstable/powerpc, gcc-3.2 ICEs on a file that gcc-2.95 handles fine. Attemps were made with gcc-2.95 (success), gcc-3.2 (fail), and gcc-snapshot (fail). Using -O0 or omitting -fPIC doesn't show the ICE. $ gcc -c -fPIC -O1 pack.i ../functions/pack.c: In function `php3_unpack': ../functions/pack.c:807: error: unrecognizable insn: (insn 1275 1022 3 0 (nil) (set (reg/v:DF 311) (const_double:DF 0.0 [0x0.0p+0])) -1 (nil) (nil)) ../functions/pack.c:807: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions. [appending the source in a followup] Release: 3.2.1 (Debian) (Debian unstable) Environment: System: Debian GNU/Linux (unstable) Architecture: powerpc
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