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

Attachment: pr94820-v1.patch
Description: pr94820-v1.patch

Reply via email to