Since fix_trunc_expr is not handled we get an ICE. int main() { double d = 1.0; char x[(int) d]; return 0; } Here is the tree which is aborting at this point: <fix_trunc_expr 0x400da76c type <integer_type 0x400505e8 int asm_written SI size <integer_cst 0x4004e21c constant 32> unit size <integer_cst 0x4004e2a8 constant 4> align 32 symtab 1074991232 alias set -1 precision 32 min <integer_cst 0x4004e280 -2147483648> max <integer_cst 0x4004e294 2147483647> pointer_to_this <pointer_type 0x4005c0d8>> arg 0 <var_decl 0x4012b0d8 d type <real_type 0x4005be58 double asm_written DF size <integer_cst 0x4004e5b4 constant 64> unit size <integer_cst 0x4004e938 constant 8> align 64 symtab 1074991488 alias set -1 precision 64 pointer_to_this <pointer_type 0x4005c000>> used tree_1 tree_2 DF file pr14492.cc line 2 size <integer_cst 0x4004e5b4 64> unit size <integer_cst 0x4004e938 8> align 64 context <function_decl 0x40127d80 main> initial <real_cst 0x400cfde0 1.0e+0> (mem/i:DF (plus:SI (reg/f:SI 20 frame) (const_int -8 [0xfffffff8])) [0 d+0 S8 A64]) chain <var_decl 0x4012b21c x type <array_type 0x4012b1b0> tree_1 BLK file pr14492.cc line 3 size <mult_expr 0x4005d1f8 type <integer_type 0x4005ba20 bit_size_type> side-effects arg 0 <non_lvalue_expr 0x400da884 type <integer_type 0x4005ba20 bit_size_type> side-effects readonly arg 0 <nop_expr 0x400da834 type <integer_type 0x4005ba20 bit_size_type> side-effects readonly arg 0 <non_lvalue_expr 0x400da820 type <integer_type 0x4005b9b4 unsigned int> side-effects readonly arg 0 <nop_expr 0x400da80c>>>> arg 1 <integer_cst 0x4004ea8c constant 8>> unit size <non_lvalue_expr 0x400da8d4 type <integer_type 0x4005b9b4 unsigned int> side-effects readonly arg 0 <nop_expr 0x400da8c0 type <integer_type 0x4005b9b4 unsigned int> side-effects readonly arg 0 <save_expr 0x4004c220 type <integer_type 0x4005baf8> side-effects readonly asm_written used noplaceholder arg 0 <nop_expr 0x400da7a8 type <integer_type 0x4005baf8> arg 0 <fix_trunc_expr 0x400da76c>> arg 1 <function_decl 0x40127d80 main> rtl 2 (reg:SI 0 ax [72]) >>> align 32 context <function_decl 0x40127d80 main> (mem/s:BLK (reg:SI 83) [0 x+0 A8])>>>
Confirmed. The good news is that the bug is already fixed on mainline by Richard Kenner's patch: http://gcc.gnu.org/ml/gcc-cvs/2004-04/msg00406.html Does a backport make sense?
More than just that kenner's patch fixed another regression dealing with VLA types so I should expect that kenner's patch be backported for both 3.3.4 and 3.4.1.
Postponed until GCC 3.4.2. Kenner, would you please take the time to backport your patch to 3.4.2?
Broke : Search converges between 2003-02-28-trunk (#195) and 2003-03-01-trunk (#196). Fixed on the mainline : Search converges between 2004-04-10-trunk (#448) and 2004-04-20-trunk (#449).
*** Bug 17076 has been marked as a duplicate of this bug. ***
Just for reference, here's the testcase from PR17076: =========================== struct A { int j; }; void foo() { int i[A().j]; } ===========================
Kenner, this is a second request that you backport your patch.
Subject: Re: [3.4 regression] ICE in loc_descriptor_from_tree (fix_trunc_expr) That's a pretty big patch to fix a pretty pathalogical case. I'd much prefer to just add a case for FIX_TRUNC_EXPR to loc_descriptor_from_tree that returns 0. That's a much safer approach for a release branch.
Kenner, thanks for the reply. Would you be willing to prepare/test a patch that does as you suggest, then?
*** This bug has been marked as a duplicate of 14492 ***
Subject: Re: [3.4 regression] ICE in loc_descriptor_from_tree (fix_trunc_expr) Kenner, thanks for the reply. Would you be willing to prepare/test a patch that does as you suggest, then? It's literally a two-line patch, but I'm not sure I have a testing environment that works with the 3.4 branch. I'm away this week and will check when I get back.