From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20800 invoked by alias); 27 Nov 2007 18:27:56 -0000 Received: (qmail 19843 invoked by uid 48); 27 Nov 2007 18:27:40 -0000 Date: Tue, 27 Nov 2007 18:27:00 -0000 Subject: [Bug target/34250] New: ICE in find_constant_pool_ref X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "matz at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-11/txt/msg02652.txt.bz2 This was triggered by a patch of ours on the SLES10 compiler, which is 4.1.2 based. But it can be seen without any patches, for 4.1.x and trunk at least. I'm sure the other compilers in between have the same problem, as the code in the s390 backend is designed to error in these cases. Anyway, do this: % cat try.c void func2(void) { __asm__ ("#bla" : : "g" ("consta"), "g" ("constb") ); } % ./gcc/cc1 -quiet -m31 -O try.c try.c: In function ‘func2’: try.c:4: internal compiler error: in find_constant_pool_ref, at config/s390/s390.c:5171 You need 31bit mode, otherwise this code path doesn't trigger. The problem is, that find_constant_pool_ref is designed to handle only max one reference to the constant pool per instruction (multiple ones to the same constant are allowed, but not multiple different ones). For normal instructions this is okay, but as can be seen above it's trivial to trigger this with asm instructions. The only fix I can imagine is to actually deal with this situation and iterate over possibly many literal pool refs. -- Summary: ICE in find_constant_pool_ref Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: matz at gcc dot gnu dot org GCC target triplet: s390-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250