> -Original Message-
> From: Martin Jambor
> Sent: Tuesday, July 27, 2021 5:39 PM
> To: JiangNing OS ; Richard Biener
>
> Cc: GCC Patches ; Jan Hubicka
> Subject: RE: [RFC] ipa: Adjust references to identify read-only globals
>
> Hi,
>
> On Tue
> Since it has been pre-approved by Honza, I would like to commit it to master
> soon. Nevertheless, Jiangning, I am OK to wait a day or so if you can give it
> another test on your setup.
>
I failed to apply your patch, so could you please provide a patch file instead?
patch: malformed
> -Original Message-
> From: Gcc-patches bounces+jiangning=os.amperecomputing@gcc.gnu.org> On Behalf Of
> Martin Jambor
> Sent: Wednesday, June 30, 2021 4:19 AM
> To: GCC Patches
> Cc: Jan Hubicka
> Subject: [RFC] ipa: Adjust references to identify read-only globals
>
> Hi,
>
>
In reality, a lot of users are still using old gcc versions running on new
hardware. OpenJDK is a typical example, I think.
> -Original Message-
> From: Richard Earnshaw
> Sent: Friday, May 1, 2020 6:41 PM
> To: JiangNing OS ; Kyrylo Tkachov
> ; Andrew Pinski ; Florian
Hi Kyrill,
Can it be backported to gcc 8/9/10 branches?
Thanks,
-Jiangning
> -Original Message-
> From: Gcc-patches On Behalf Of Kyrylo
> Tkachov
> Sent: Thursday, April 30, 2020 8:27 PM
> To: Kyrylo Tkachov ; Andrew Pinski
> ; Florian Weimer
> Cc: gcc-patches@gcc.gnu.org;
Hi Jason,
This commit caused boot-strap failure on aarch64. Is it a bug? Can this be
fixed ASAP?
../../gcc/gcc/expmed.c:5602:19: error: ���int_mode��� may be used uninitialized
in this function [-Werror=maybe-uninitialized]
5602 | scalar_int_mode int_mode;
| ^~~~
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org On
> Behalf Of JiangNing OS
> Sent: Thursday, August 22, 2019 8:24 AM
> To: Prathamesh Kulkarni ; James Greenhalgh
>
> Cc: gcc Patches ; Richard Sandiford
> ; Kyrill Tkachov ;
> nd
&
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org On
> Behalf Of Prathamesh Kulkarni
> Sent: Thursday, August 22, 2019 2:36 AM
> To: James Greenhalgh
> Cc: gcc Patches ; Richard Sandiford
> ; Kyrill Tkachov ;
> nd
> Subject: Re: PR90724 - ICE with __sync_bool_compare_and_swap
> -Original Message-
> From: Martin Sebor
> Sent: Thursday, July 25, 2019 2:08 AM
> To: Jeff Law ; JiangNing OS
> ; gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for
> conditional store optimization
>
> On 7/24/
This patch is to fix PR91195. Is it OK for trunk?
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 711a31ea597..4db36644160 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2019-07-22 Jiangning Liu
+
+ PR middle-end/91195
+ * tree-ssa-phiopt.c
Hi Honza,
It seems this commit caused gcc bootstrap failure on aarch64 as below,
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
gcc/dwarf2out.o differs
gcc/var-tracking.o differs
gcc/aarch64.o differs
make[2]: *** [compare] Error 1
Do you know the
Biener
> Cc: JiangNing OS ; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] improve ifcvt optimization (PR rtl-optimization/89430)
>
> On 6/21/19 6:23 AM, Richard Biener wrote:
> >
> > That looks like a pretty easy form to analyze. I'd suggest looking
> > throug
Hi,
FYI. This patch works for my application LTO build on aarch64.
Thanks,
-Jiangning
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Jan Hubicka
> Sent: Monday, July 1, 2019 8:22 PM
> To: Christophe Lyon
> Cc: Eric Botcazou ; gcc Patches
-
> From: Jan Hubicka
> Sent: Thursday, June 27, 2019 2:29 PM
> To: JiangNing OS
> Cc: Eric Botcazou ; Christophe Lyon
> ; gcc Patches ;
> Richard Biener ; d...@dcepelik.cz; Martin Liška
>
> Subject: Re: Use ODR for canonical types construction in LTO
>
> > Hi,
>
Hi,
This commit https://gcc.gnu.org/viewcvs/gcc?view=revision=272628 is
breaking trunk LTO on some real benchmarks, so can it be fixed or reverted? For
example,
lto1: error: type variant differs by TYPE_CXX_ODR_P
constant 256>
unit-size constant 32>
align:64 warn_if_not_align:0
Hi Jeff,
Appreciate your effort to review my patch! I've updated my patch as attached.
See my answers below.
> in current function, so the store speculation can be avoided.
> So at a high level should we be doing this in gimple rather than RTL?
> We're going to have a lot more information about
Hi,
May I know any feedback comments to this patch?
Thanks,
-Jiangning
From: Kyrill Tkachov
Sent: Friday, May 24, 2019 10:55 PM
To: JiangNing OS ; gcc-patches@gcc.gnu.org
Cc: ebotca...@adacore.com; ste...@gcc.gnu.org; l...@redhat.com
Subject: Re: [PATCH] improve ifcvt optimization (PR rtl
> -Original Message-
> From: Richard Biener
> Sent: Wednesday, May 8, 2019 3:35 PM
> To: JiangNing OS
> Cc: gcc-patches@gcc.gnu.org; Richard Biener ;
> pins...@gcc.gnu.org
> Subject: Re: Fixing ifcvt issue as exposed by BZ89430
>
> On Thu, Feb 28, 2019 at 1:
Hi Jeff,
Yes. The latter one "[PATCH] improve ifcvt optimization (PR
rtl-optimization/89430)" supersedes the earlier one " Fixing ifcvt issue as
exposed by BZ89430".
Thanks,
-Jiangning
-Original Message-
From: Jeff Law
Sent: Tuesday, April 30, 2019 11:54 PM
To
This patch is to fix a missing ifcvt opportunity in back-end. For the simple
case below,
if (...)
x = a; /* x is memory */
/* no else */
We can generate conditional move and remove the branch as below if the target
cost is acceptable.
r1 = x
r2 = a
cmp ...
csel r3, r1, r2, cond
x = r3
To solve BZ89430 the followings are needed,
(1) The code below in noce_try_cmove_arith needs to be fixed.
/* ??? We could handle this if we knew that a load from A or B could
not trap or fault. This is also true if we've already loaded
from the address along the path from ENTRY. */
21 matches
Mail list logo
