From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4884 invoked by alias); 23 Apr 2003 20:16:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 4861 invoked by uid 71); 23 Apr 2003 20:16:00 -0000 Date: Wed, 23 Apr 2003 20:16:00 -0000 Message-ID: <20030423201600.4849.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: David Edelsohn Subject: Re: optimization/10315: [3.2/3.3 regression] [powerpc] ICE: in extract_insn, at recog.c:2175 Reply-To: David Edelsohn X-SW-Source: 2003-04/txt/msg00997.txt.bz2 List-Id: The following reply was made to PR optimization/10315; it has been noted by GNATS. From: David Edelsohn To: Geoff Keating 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