[PATCH PR96230] driver: ICE in process_command, at gcc.c:5095
Hi, This is a simple fix for pr96230. When the dumpbase is an empty string, we should add check for !*dumpbase in process_command. The option -dumpbase "" is used gcc-defs.exp: # This option restores naming of aux and dump output files # after input files when multiple input files are named, # instead of getting them combined with the output name. lappend options "additional_flags=-dumpbase \"\"" Bootstrap and tested on aarch64 and x86 Linux platform. No new regression witnessed. Any suggestion? Thanks, Haijian Zhang pr96230-v1.diff Description: pr96230-v1.diff
[PATCH PR94274] fold phi whose incoming args are defined from binary
Hi, This is a experimental fix for pr94274. For if/else structure, when the expressions is binary operation and have a common subexpression, and the opcode is the same, we can fold the merging phi node in tree_ssa_phiopt_worker (ssa-phiopt). It can be optimized to do csel first and then do binary operations. This can eliminate one or more instructions. And this patch is effective for 500.perlbench_r in spec2017. Bootstrap and tested on aarch64/x86_64 Linux platform. No new regression witnessed. Any suggestion? Thanks, Haijian Zhang pr94274-v1.diff Description: pr94274-v1.diff
RE: [PATCH PR95523] aarch64:ICE in register_tuple_type，at config/aarch64/aarch64-sve-builtins.cc:3434
Thanks for viewing and pushing this.
Thanks,
Haijian Zhang
> -Original Message-
> From: Richard Sandiford [mailto:richard.sandif...@arm.com]
> Sent: Thursday, June 11, 2020 12:01 AM
> To: Zhanghaijian (A)
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95523] aarch64:ICE in register_tuple_type，at
> config/aarch64/aarch64-sve-builtins.cc:3434
>
> Hi,
>
> "Zhanghaijian (A)" writes:
> > This is a simple fix for pr95523.
> > When registering the tuple type in register_tuple_type, the TYPE_ALIGN
> (tuple_type) will be changed by -fpack-struct=n.
> > We need to maintain natural alignment in handle_arm_sve_h.
> > Bootstrap and tested on aarch64 Linux platform. No new regression
> witnessed.
>
> Sorry for dropping the ball on the bugzilla PR and not replying to your
> comment
> there. For the record...
>
> IMO it's a misfeature that -fpack-struct=N and “#pragma pack (1)”
> override explicit alignments. E.g. it means that for:
>
> struct __attribute__((packed)) s1 { __attribute__((aligned(2))) int x; };
> #pragma pack (1)
> struct s2 { __attribute__((aligned(2))) int x; };
>
> s1 has alignment 2 but s2 has alignment 1. There's a comment about this in
> stor-layout.c:
>
> /* Should this be controlled by DECL_USER_ALIGN, too? */
> if (mfa != 0)
> SET_DECL_ALIGN (decl, MIN (DECL_ALIGN (decl), mfa));
>
> I think the condition probably should have checked DECL_USER_ALIGN.
>
> However, there's no telling whether anything now relies on the current
> behaviour, and since this bug is about internally-defined structures, it's
> probably not a good motivating example for changing the code above.
>
> Also, I agree the patch is a clean way of avoiding the problem, and is
> probably
> more robust than the DECL_USER_ALIGN thing would have been.
>
> Pushed to master, thanks.
>
> Richard
[PATCH PR95523] aarch64:ICE in register_tuple_type，at config/aarch64/aarch64-sve-builtins.cc:3434
Hi, This is a simple fix for pr95523. When registering the tuple type in register_tuple_type, the TYPE_ALIGN (tuple_type) will be changed by -fpack-struct=n. We need to maintain natural alignment in handle_arm_sve_h. Bootstrap and tested on aarch64 Linux platform. No new regression witnessed. Any suggestion? Thanks, Haijian Zhang pr95523-v1.diff Description: pr95523-v1.diff
RE: [PATCH PR94708] [8/9/10 Regression] pr94780.c fails with ICE on aarch64
Thanks for your suggestions. I have modified accordingly. Is the v2 patch ok? Please help install it this patch is ok, as I am not a committer. >From 15d8675676b3fcced3fa5695b3d9c37f3ec3be18 Mon Sep 17 00:00:00 2001 From: Haijian Zhang Date: Wed, 29 Apr 2020 15:00:00 +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 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/ChangeLog | 8 gcc/config/aarch64/aarch64-builtins.c | 15 +-- 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index c4afdb053f7..f87866622c6 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,11 @@ +2020-04-29 Haijian Zhang + + 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. + 2020-04-29 Richard Biener * tree-ssa-loop-im.c (ref_always_accessed::operator ()): 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 Thanks, Haijian Zhang > -Original Message- > From: Jakub Jelinek [mailto:ja...@redhat.com] > Sent: Wednesday, April 29, 2020 3:21 PM > To: Zhanghaijian (A) > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94708] [8/9/10 Regression] pr94780.c fails with ICE on > aarch64 > > On Wed, Apr 29, 2020 at 07:16:53AM +, Zhanghaijian (A) wrote: > > 2020-04-29 Haijian Zhang > > Two spaces before < rather than just one. > > > 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. > > Ok for trunk, thanks. > > > 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, &g
[PATCH PR94708] [8/9/10 Regression] pr94780.c fails with ICE on aarch64
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 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 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
RE: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max
> -Original Message- > From: Richard Biener [mailto:richard.guent...@gmail.com] > Sent: Friday, April 24, 2020 2:19 PM > To: Zhanghaijian (A) > Cc: Segher Boessenkool ; > gcc-patches@gcc.gnu.org > Subject: Re: [PATCH PR94708] rtl combine should consider NaNs when generate > fp min/max > > On Fri, Apr 24, 2020 at 5:05 AM Zhanghaijian (A) > wrote: > > > > Thanks for your suggestions. For safety, I put back > flag_unsafe_math_optimizations. > > Attached please find the v3 patch which is suitable for git am. Bootstrap > > and > tested on aarch64 Linux platform. > > Is the v3 patch ok? > > OK. Thanks for reviewing this. Please help install this patch as I am not a committer. Thanks, Haijian Zhang
RE: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max
Thanks for your suggestions. For safety, I put back
flag_unsafe_math_optimizations.
Attached please find the v3 patch which is suitable for git am. Bootstrap and
tested on aarch64 Linux platform.
Is the v3 patch ok?
>From aafcad7ed5d3d156eee1cabbb4958e2cce7899c6 Mon Sep 17 00:00:00 2001
From: z00219097
Date: Fri, 24 Apr 2020 08:56:25 +0800
Subject: [PATCH] rtl combine should consider NaNs when generate fp min/max
[PR94708]
As discussed on PR94708, it's unsafe for rtl combine to generate fp
min/max under -funsafe-math-optimizations, considering NaNs. In
addition to flag_unsafe_math_optimizations check, we also need to
do extra mode feature testing here: && !HONOR_NANS (mode)
&& !HONOR_SIGNED_ZEROS (mode)
2020-04-24 Haijian Zhang
gcc/
PR rtl-optimization/94708
* combine.c (simplify_if_then_else): Add check for
!HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode).
gcc/testsuite/
PR fortran/94708
* gfortran.dg/pr94708.f90: New test.
---
gcc/ChangeLog | 6 ++
gcc/combine.c | 5 -
gcc/testsuite/ChangeLog | 5 +
gcc/testsuite/gfortran.dg/pr94708.f90 | 13 +
4 files changed, 28 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr94708.f90
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index cf97cfed626..6032e681d7f 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2020-04-24 Haijian Zhang
+
+ PR rtl-optimization/94708
+ * combine.c (simplify_if_then_else): Add check for
+ !HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode).
+
2020-04-23 Martin Sebor
PR driver/90983
diff --git a/gcc/combine.c b/gcc/combine.c
index cff76cd3303..4c324f38660 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -6643,7 +6643,10 @@ simplify_if_then_else (rtx x)
/* Look for MIN or MAX. */
- if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations)
+ if ((! FLOAT_MODE_P (mode)
+ || (flag_unsafe_math_optimizations
+ && !HONOR_NANS (mode)
+ && !HONOR_SIGNED_ZEROS (mode)))
&& comparison_p
&& rtx_equal_p (XEXP (cond, 0), true_rtx)
&& rtx_equal_p (XEXP (cond, 1), false_rtx)
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 86331cd1211..4d80ee3a3a0 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2020-04-24 Haijian Zhang
+
+ PR fortran/94708
+ * gfortran.dg/pr94708.f90: New test.
+
2020-04-23 Martin Sebor
PR driver/90983
diff --git a/gcc/testsuite/gfortran.dg/pr94708.f90
b/gcc/testsuite/gfortran.dg/pr94708.f90
new file mode 100644
index 000..9b5f1389f09
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr94708.f90
@@ -0,0 +1,13 @@
+! { dg-do compile { target aarch64*-*-* } }
+! { dg-options "-O2 -funsafe-math-optimizations -fdump-rtl-combine" }
+
+subroutine f(vara,varb,varc,res)
+ REAL, INTENT(IN) :: vara,varb,varc
+ REAL, INTENT(out) :: res
+
+ res = vara
+ if (res .lt. varb) res = varb
+ if (res .gt. varc) res = varc
+end subroutine
+
+! { dg-final { scan-rtl-dump-not "smin" "combine" } }
--
2.19.1
-Original Message-
From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
Sent: Friday, April 24, 2020 1:05 AM
To: Zhanghaijian (A)
Cc: Richard Biener ; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp
min/max
Hi!
On Thu, Apr 23, 2020 at 02:34:03PM +, Zhanghaijian (A) wrote:
> Thanks for your suggestions. I have modified accordingly.
> Attached please find the adapted patch. Bootstrap and tested on aarch64 Linux
> platform.
> Does the v2 patch look better?
>
> diff --git a/gcc/combine.c b/gcc/combine.c index
> cff76cd3303..ad8a385fc48 100644
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -6643,7 +6643,8 @@ simplify_if_then_else (rtx x)
>
>/* Look for MIN or MAX. */
>
> - if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations)
> + if ((! FLOAT_MODE_P (mode)
> + || (!HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode)))
>&& comparison_p
>&& rtx_equal_p (XEXP (cond, 0), true_rtx)
>&& rtx_equal_p (XEXP (cond, 1), false_rtx)
> > The GENERIC folding routine producing min/max is avoiding it when
> > those are honored (and it doesn't check
> > flag_unsafe_math_optmizations at all).
> >
> > Certainly the patch is an incremental correct fix, with the flag
> > testing replaced by the mode feature testing.
>
> Yeah, and the SMAX etc. definition is so weak that it isn't obvious
> that this combine transform is valid without this flag. We can or
> should fix that, of course :-)
Please put flag_unsafe_math_optimizations back? It isn't clear at all that we
do not need it.
Also, do you have a changelog entry?
Segher
pr94708-v3.patch
Description: pr94708-v3.patch
RE: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max
Thanks for your suggestions. I have modified accordingly. Attached please find the adapted patch. Bootstrap and tested on aarch64 Linux platform. Does the v2 patch look batter? diff --git a/gcc/combine.c b/gcc/combine.c index cff76cd3303..ad8a385fc48 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -6643,7 +6643,8 @@ simplify_if_then_else (rtx x) /* Look for MIN or MAX. */ - if ((! FLOAT_MODE_P (mode) || flag_unsafe_math_optimizations) + if ((! FLOAT_MODE_P (mode) + || (!HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode))) && comparison_p && rtx_equal_p (XEXP (cond, 0), true_rtx) && rtx_equal_p (XEXP (cond, 1), false_rtx) Thanks, Haijian Zhang -Original Message- From: Segher Boessenkool [mailto:seg...@kernel.crashing.org] Sent: Thursday, April 23, 2020 7:38 PM To: Richard Biener Cc: Zhanghaijian (A) ; gcc-patches@gcc.gnu.org Subject: Re: [PATCH PR94708] rtl combine should consider NaNs when generate fp min/max Hi! On Thu, Apr 23, 2020 at 11:05:22AM +0200, Richard Biener wrote: > On Thu, Apr 23, 2020 at 10:42 AM Zhanghaijian (A) > wrote: > > This is a simple fix for pr94708. > > It's unsafe for rtl combine to generate fp min/max under > > -funsafe-math-optimizations, considering NaNs. > > We can only do this kind of transformation under > > -funsafe-math-optimizations and -ffinite-math-only. > > Bootstrap and tested on aarch64 Linux platform. No new regression witnessed. > > > > Any suggestion? > > Please do not check flags, instead use && !HONOR_NANS (mode) Yeah, good point. > What about signed zeros? -funsafe-math-optimizations implies -fno-signed-zeros. > The GENERIC folding routine producing > min/max is avoiding it when those are honored (and it doesn't check > flag_unsafe_math_optmizations at all). > > Certainly the patch is an incremental correct fix, with the flag > testing replaced by the mode feature testing. Yeah, and the SMAX etc. definition is so weak that it isn't obvious that this combine transform is valid without this flag. We can or should fix that, of course :-) Segher pr94708-v2.patch Description: pr94708-v2.patch
[PATCH PR94708] rtl combine should consider NaNs when generate fp min/max
Hi This is a simple fix for pr94708. It's unsafe for rtl combine to generate fp min/max under -funsafe-math-optimizations, considering NaNs. We can only do this kind of transformation under -funsafe-math-optimizations and -ffinite-math-only. Bootstrap and tested on aarch64 Linux platform. No new regression witnessed. Any suggestion? Thanks, Haijian Zhang pr94708-v1.patch Description: pr94708-v1.patch
