From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24464 invoked by alias); 19 Jan 2004 19:56:55 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 24446 invoked from network); 19 Jan 2004 19:56:54 -0000 Received: from unknown (HELO satan.blackhosts) (80.54.212.30) by sources.redhat.com with SMTP; 19 Jan 2004 19:56:54 -0000 Received: from satan.blackhosts (localhost [127.0.0.1]) by satan.blackhosts (8.12.10/8.12.10) with ESMTP id i0JK1XYN019972 for ; Mon, 19 Jan 2004 21:01:33 +0100 Received: (from qboosh@localhost) by satan.blackhosts (8.12.10/8.12.10/Submit) id i0JK1Xso019969 for gcc-bugs@gcc.gnu.org; Mon, 19 Jan 2004 21:01:33 +0100 Date: Mon, 19 Jan 2004 19:56:00 -0000 From: Jakub Bogusz To: gcc-bugs@gcc.gnu.org Subject: gcc 3.3.2 ICE on altivec - bug category question Message-ID: <20040119200132.GA19295@satan.blackhosts> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-SW-Source: 2004-01/txt/msg02250.txt.bz2 List-Id: I'm getting an ICE using gcc 3.3.2 (doesn't matter here if PR target/11793 fix is applied or not, I tried both versions) on ppc-linux system, on the following code (already preprocessed and simplified from original one): typedef __attribute__((vector_size(16))) signed int vector_s_t; static vector_s_t my_vec_and (vector_s_t const A, vector_s_t const B) { return __builtin_altivec_vand(A, B); } $ gcc -c alt.i -maltivec alt.i: In function `my_vec_and': alt.i:6: error: unrecognizable insn: (insn 5 4 30 0 (nil) (set (reg:V4SI 119) (mem/u/f:V4SI (plus:SI (reg/f:SI 67 ap) (const_int 8 [0x8])) [0 B+0 S16 A128])) -1 (nil) (nil)) alt.i:6: internal compiler error: in extract_insn, at recog.c:2175 Please submit a full bug report, with preprocessed source if appropriate. But: $ gcc -c alt.i -maltivec -mabi=altivec $ Is suppose that altivec ABI can be needed to return vector... but I haven't found such information - is it true? And thus, does it fall under "ice-on-valid-code" or "ice-on-invalid-code"? Can it be expected to be fixed in 3.3.x line, or 3.4/3.5? -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ PLD Team http://www.pld-linux.org/