public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Richard Henderson <rth@redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175 Date: Thu, 24 Apr 2003 04:56:00 -0000 [thread overview] Message-ID: <20030424045600.28439.qmail@sources.redhat.com> (raw) The following reply was made to PR optimization/10315; it has been noted by GNATS. 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; } \f /* 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])); } \f /* Initialize a variable CUM of type CUMULATIVE_ARGS
next reply other threads:[~2003-04-24 4:56 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-04-24 4:56 Richard Henderson [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-04-25 14:06 David Edelsohn 2003-04-23 22:56 Richard Henderson 2003-04-23 20:16 David Edelsohn 2003-04-23 18:26 Geoff Keating 2003-04-23 3:16 David Edelsohn 2003-04-07 7:16 Steven Bosscher 2003-04-05 13:56 Matthias Klose
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030424045600.28439.qmail@sources.redhat.com \ --to=rth@redhat.com \ --cc=gcc-prs@gcc.gnu.org \ --cc=nobody@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).