Hi This is a simple fix for pr94820. The PR was only fixed on i386, the same error was also reported on aarch64. This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification the var gets the right DECL_CONTEXT and is added to local decls. Without that, e.g. tree-nested.c ICEs on those. Attached please find the v1 patch which is suitable for git am. Bootstrap and tested on aarch64 Linux platform. No new regression witnessed.
>From 538bafed0d4704b588769a97756e4b5a6312b7ad Mon Sep 17 00:00:00 2001 From: z00219097 <z.zhanghaij...@huawei.com> Date: Wed, 29 Apr 2020 14:30:23 +0800 Subject: [PATCH] aarch64: Fix up aarch64_atomic_assign_expand_fenv [PR94820] This function, because it is sometimes called even outside of function bodies, uses create_tmp_var_raw rather than create_tmp_var. But in order for that to work, when first referenced, the VAR_DECLs need to appear in a TARGET_EXPR so that during gimplification the var gets the right DECL_CONTEXT and is added to local decls. Without that, e.g. tree-nested.c ICEs on those. 2020-04-29 Haijian Zhang <z.zhanghaij...@huawei.com> PR target/94820 * config/aarch64/aarch64-builtins.c (aarch64_atomic_assign_expand_fenv): Use TARGET_EXPR instead of MODIFY_EXPR for first assignment to fenv_cr, fenv_sr and new_fenv_var. --- gcc/config/aarch64/aarch64-builtins.c | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c index 5744e68ea08..95213cd70c8 100644 --- a/gcc/config/aarch64/aarch64-builtins.c +++ b/gcc/config/aarch64/aarch64-builtins.c @@ -2313,10 +2313,12 @@ aarch64_atomic_assign_expand_fenv (tree *hold, tree *clear, tree *update) mask_sr = build_int_cst (unsigned_type_node, ~(AARCH64_FE_ALL_EXCEPT)); - ld_fenv_cr = build2 (MODIFY_EXPR, unsigned_type_node, - fenv_cr, build_call_expr (get_fpcr, 0)); - ld_fenv_sr = build2 (MODIFY_EXPR, unsigned_type_node, - fenv_sr, build_call_expr (get_fpsr, 0)); + ld_fenv_cr = build4 (TARGET_EXPR, unsigned_type_node, + fenv_cr, build_call_expr (get_fpcr, 0), + NULL_TREE, NULL_TREE); + ld_fenv_sr = build4 (TARGET_EXPR, unsigned_type_node, + fenv_sr, build_call_expr (get_fpsr, 0), + NULL_TREE, NULL_TREE); masked_fenv_cr = build2 (BIT_AND_EXPR, unsigned_type_node, fenv_cr, mask_cr); masked_fenv_sr = build2 (BIT_AND_EXPR, unsigned_type_node, fenv_sr, mask_sr); @@ -2348,8 +2350,9 @@ aarch64_atomic_assign_expand_fenv (tree *hold, tree *clear, tree *update) __atomic_feraiseexcept (new_fenv_var); */ new_fenv_var = create_tmp_var_raw (unsigned_type_node); - reload_fenv = build2 (MODIFY_EXPR, unsigned_type_node, - new_fenv_var, build_call_expr (get_fpsr, 0)); + reload_fenv = build4 (TARGET_EXPR, unsigned_type_node, + new_fenv_var, build_call_expr (get_fpsr, 0), + NULL_TREE, NULL_TREE); restore_fnenv = build_call_expr (set_fpsr, 1, fenv_sr); atomic_feraiseexcept = builtin_decl_implicit (BUILT_IN_ATOMIC_FERAISEEXCEPT); update_call = build_call_expr (atomic_feraiseexcept, 1, -- 2.19.1 Any suggestion? Thanks, Haijian Zhang
pr94820-v1.patch
Description: pr94820-v1.patch