Created attachment 22700 [details] reduced testcase Compiler output: $ gcc -O -flto -ftree-parallelize-loops=4 -gdwarf-3 pr46879.c In file included from :0:0: pr46879.c: In function 'main': pr46879.c:18:5: internal compiler error: in separate_decls_in_region_debug_bind, at tree-parloops.c:778 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: /mnt/svn/gcc-trunk/binary-167643-lto-fortran-checking-yes-rtl-df/bin/gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status Tested revisions: r167643 - crash r165699 - crash r161659 - OK 4.5 r166509 - OK
This looks like a lto bug to me. 1765 tree *basep = &op; 1766 while (handled_component_p (*basep)) 1767 basep = &TREE_OPERAND (*basep, 0); 1768 if (TREE_CODE (*basep) == VAR_DECL 1769 && !auto_var_in_fn_p (*basep, current_function_decl)) 1770 { 1771 bool volatilep = TREE_THIS_VOLATILE (*basep); 1772 *basep = build2 (MEM_REF, TREE_TYPE (*basep), 1773 build_fold_addr_expr (*basep), 1774 build_int_cst (build_pointer_type 1775 (TREE_TYPE (*basep)), 0)); 1776 TREE_THIS_VOLATILE (*basep) = volatilep; 1777 } in output_gimple_stmt is not suitable for the first argument of a GIMPLE_DEBUG stmt - where the argument must be a DECL.
(In reply to comment #1) > This looks like a lto bug to me. > 1765 tree *basep = &op; > 1766 while (handled_component_p (*basep)) > 1767 basep = &TREE_OPERAND (*basep, 0); > 1768 if (TREE_CODE (*basep) == VAR_DECL > 1769 && !auto_var_in_fn_p (*basep, current_function_decl)) > 1770 { > 1771 bool volatilep = TREE_THIS_VOLATILE (*basep); > 1772 *basep = build2 (MEM_REF, TREE_TYPE (*basep), > 1773 build_fold_addr_expr (*basep), > 1774 build_int_cst (build_pointer_type > 1775 (TREE_TYPE (*basep)), 0)); > 1776 TREE_THIS_VOLATILE (*basep) = volatilep; > 1777 } > > in output_gimple_stmt is not suitable for the first argument of a GIMPLE_DEBUG > stmt - where the argument must be a DECL. Hm, well. Then the debug machinery has to deal with type mismatches I guess. But I wonder why we have debug-stmts for global variables anyway? I thought they are only used for registers.
(In reply to comment #2) > Hm, well. Then the debug machinery has to deal with type mismatches I guess. Well, all the debug machinery cares is that the var has the original, declared type. > But I wonder why we have debug-stmts for global variables anyway? I thought > they are only used for registers. It is not a global variable, it is a VAR_DECL with DECL_ABSTRACT_ORIGIN PARM_DECL in bar, i.e. optimized away parameter/automatic variable. It is a non-localized var in main, because it is never referenced there, except for GIMPLE_DEBUG.
(In reply to comment #3) > (In reply to comment #2) > > Hm, well. Then the debug machinery has to deal with type mismatches I guess. > > Well, all the debug machinery cares is that the var has the original, declared > type. > > > But I wonder why we have debug-stmts for global variables anyway? I thought > > they are only used for registers. > > It is not a global variable, it is a VAR_DECL with DECL_ABSTRACT_ORIGIN > PARM_DECL in bar, i.e. optimized away parameter/automatic variable. It is a > non-localized var in main, because it is never referenced there, except for > GIMPLE_DEBUG. Ah, ok. The fix is then to amend the 1768 if (TREE_CODE (*basep) == VAR_DECL 1769 && !auto_var_in_fn_p (*basep, current_function_decl)) check properly. The easiest check would be && !is_gimple_debug, or a auto_var_in_fn_p variant without a specific function, thus auto_var_p.
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00911.html
Author: jakub Date: Mon Dec 13 17:37:20 2010 New Revision: 167755 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=167755 Log: PR lto/46879 * lto-streamer-out.c (output_gimple_stmt): Never replace first GIMPLE_DEBUG argument with MEM_REF. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c
Fixed.