Re: [PATCH, tree-opt]: Fix PR5118, ICE: tree check: expected tree that contains ‘typed’ structure, have ‘b lock’ in fold_checksum_tree

[Richard Guenther <richard dot guenther at gmail dot com>]

On Thu, Nov 17, 2011 at 8:47 PM, Uros Bizjak <ubizjak@gmail.com> wrote:
> Hello!
>
> Currently, bootstrap crashes with --enable-stage1-checking=all with:
>
> ../../../libgcc/libgcc2.c:553:3: internal compiler error: tree check: expected
> tree that contains ‘typed’ structure, have ‘block’ in fold_checksum_tree, at
> fold-const.c:14160
>
> The problem is in fold_checksum_tree function itself, when it recurses for i.e.
>
> (gdb) p debug_tree (expr)
> ?<bind_expr 0x7ffff1ac6000
> ? ?type <void_type 0x7ffff19a5bd0 void VOID
> ? ? ? ?align 8 symtab 0 alias set -1 canonical type 0x7ffff19a5bd0
> ? ? ? ?pointer_to_this <pointer_type 0x7ffff19a5c78>>
> ---
> ? ?body <decl_expr 0x7ffff1aa3f28 type <void_type 0x7ffff19a5bd0 void>
> ? ? ? ?side-effects arg 0 <var_decl 0x7ffff1ac5140 __w>
> ? ? ? ?031.c:4:32>
> ? ?block <block 0x7ffff1ab6f50 used vars <var_decl 0x7ffff1ac5140 __w>>
> ? ?031.c:4:23>
>
> The function decomposes the tree expression with:
>
> ? ?case tcc_expression:
> ...
> ? ? ?len = TREE_OPERAND_LENGTH (expr);
> ? ? ?for (i = 0; i < len; ++i)
>>> ? ? ?fold_checksum_tree (TREE_OPERAND (expr, i), ctx, ht);
> ? ? ?break;
>
> where we recurse with "block" expression, that has no type. This
> recursion crashes at
>
> ?md5_process_bytes (expr, tree_size (expr), ctx);
>>> ?fold_checksum_tree (TREE_TYPE (expr), ctx, ht);
>
> The fix is fairly trivial - check for typed structure before using
> TREE_TYPE accessor, as the error said.
>
> 2011-11-17 ?Uros Bizjak ?<ubizjak@gmail.com>
>
> ? ? ? ?PR tree-optimization/51118
> ? ? ? ?* fold-const.c (fold_checksum_tree): Check for TS_TYPED structure
> ? ? ? ?before using TREE_TYPE accessor on expr.
>
> Patch was tested by bootstrapping --enable-stage1-checking=all
> configured bootstrap (which takes ages...) on x86_64-pc-linux-gnu.
>
> OK for mainline and release branches?

Ok for trunk.

Thanks,
Richard.

> Uros.
>