This is the mail archive of the
mailing list for the GCC project.
ICE compiling linux kernel
- From: Andreas Krebbel <krebbel1 at de dot ibm dot com>
- To: gcc at gcc dot gnu dot org
- Date: Tue, 13 Jul 2004 10:29:25 +0200
- Subject: ICE compiling linux kernel
- Organization: IBM Entwicklung GmbH
I've trouble compiling the linux 2.6 kernel on s390 with the current cvs
head gcc. The compile produced an ICE in
I've reduced the testcase to:
unsigned long tmp;
unsigned short ticks;
tmp = 0;
ticks = tmp;
asm volatile ("SCKC %0" : : "m" (tmp));
Compiled on 32 bit Intel with:
results in the following ICE:
test.i: In function `account_ticks':
test.i:3: error: Invalid operand to unary operator
test.i:3: internal compiler error: verify_stmts failed.
gcc -v says:
Reading specs from /usr/local/gcc-3.5/lib/gcc/i486-linux/3.5.0/specs
Configured with: ../gcc-3.5/configure -v --enable-languages=c,c++ --prefix=/usr/local/gcc-3.5
--enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-__cxa_atexit
--enable-clocale=gnu --enable-debug i486-linux
Thread model: posix
gcc version 3.5.0 20040712 (experimental)
The ICE doesn't occur with gcc from 06/28/2004!
The line with ticks=tmp; seems to be dead code but is essential for the
occurrence of the ICE as well as the implicit type cast from long to short.
Breakpoint 19, error (msgid=0x0) at ../../gcc-3.5/gcc/diagnostic.c:497
497 va_start (ap, msgid);
#0 error (msgid=0x0) at ../../gcc-3.5/gcc/diagnostic.c:497
#1 0x080baa07 in verify_expr (tp=0x6f, walk_subtrees=0xbfffecc4, data=0x0)
#2 0x083d5d6e in walk_tree (tp=0x4016a1f4, func=0x80ba640 <verify_expr>, data=0x0, htab_=0x0)
#3 0x080bb1e0 in verify_stmt (stmt=0x4016a1d4, last_in_block=0 '\0')
#4 0x080bb6b8 in verify_stmts () at tree-flow-inline.h:600
#5 0x080cb81a in execute_one_pass (pass=0x850f100) at ../../gcc-3.5/gcc/tree-optimize.c:416
#6 0x080cb918 in execute_pass_list (pass=0x850f100) at ../../gcc-3.5/gcc/tree-optimize.c:435
#7 0x080cba65 in tree_rest_of_compilation (fndecl=0x4021b5e4, nested_p=0 '\0')
In verify_expr is_gimple_val returns false for the tmp var_decl due to the following check:
if (is_gimple_variable (t)
&& is_gimple_reg_type (TREE_TYPE (t))
&& !is_gimple_reg (t))
Wherein is_gimple_reg returns false because the addressable_flag of tmp
is set which should be issued by the "m" constraint in the inline assembly.
As far as I've understood, the "m" constraint forces tmp to be placed in memory
but for the type conversion verify_expr refuses to use a temporary memory slot - but why?
Hopefully anybody who is more familiar with the gimple tree stuff could look into it.