Pushed the patch as:
https://gcc.gnu.org/pipermail/gcc-cvs/2021-November/356543.html
Qing
> On Nov 10, 2021, at 2:37 AM, Richard Biener
> wrote:
>
> On Tue, Nov 9, 2021 at 6:48 PM Qing Zhao wrote:
>>
>> So, based on the discussion so far, is the following patch good to go?
>
> OK.
>
> T
On Tue, Nov 9, 2021 at 6:48 PM Qing Zhao wrote:
>
> So, based on the discussion so far, is the following patch good to go?
OK.
Thanks,
Richard.
> Let me know if you have more comments on the following patch:
>
> (At the same time, I am testing this patch on both x86 and aarch64)
>
> thanks.
>
So, based on the discussion so far, is the following patch good to go?
Let me know if you have more comments on the following patch:
(At the same time, I am testing this patch on both x86 and aarch64)
thanks.
Qing
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 0cba95411a6..e8fd16b9c
On Tue, Nov 9, 2021 at 10:10 AM Jakub Jelinek wrote:
>
> On Tue, Nov 09, 2021 at 08:13:57AM +0100, Richard Biener wrote:
> > > Hi, I tried both the following patches:
> > >
> > > Patch1:
> > >
> > > [opc@qinzhao-ol8u3-x86 gcc]$ git diff
> > > diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> >
On Tue, Nov 09, 2021 at 08:13:57AM +0100, Richard Biener wrote:
> > Hi, I tried both the following patches:
> >
> > Patch1:
> >
> > [opc@qinzhao-ol8u3-x86 gcc]$ git diff
> > diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> > index 0cba95411a6..ca49d2b4514 100644
> > --- a/gcc/internal-fn.c
> >
On Tue, Nov 9, 2021 at 12:47 AM Qing Zhao wrote:
>
> Hi, I tried both the following patches:
>
> Patch1:
>
> [opc@qinzhao-ol8u3-x86 gcc]$ git diff
> diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
> index 0cba95411a6..ca49d2b4514 100644
> --- a/gcc/internal-fn.c
> +++ b/gcc/internal-fn.c
> @@ -
Hi, I tried both the following patches:
Patch1:
[opc@qinzhao-ol8u3-x86 gcc]$ git diff
diff --git a/gcc/internal-fn.c b/gcc/internal-fn.c
index 0cba95411a6..ca49d2b4514 100644
--- a/gcc/internal-fn.c
+++ b/gcc/internal-fn.c
@@ -3073,12 +3073,14 @@ expand_DEFERRED_INIT (internal_fn, gcall *stmt)
On Sat, Nov 6, 2021 at 10:56 AM Jakub Jelinek wrote:
>
> On Fri, Nov 05, 2021 at 05:37:25PM +, Qing Zhao wrote:
> > > On Nov 5, 2021, at 11:17 AM, Jakub Jelinek wrote:
> > >
> > > On Fri, Nov 05, 2021 at 04:11:36PM +, Qing Zhao wrote:
> > >> 3076 if (TREE_CODE (TREE_TYPE (lhs)) != B
On Fri, Nov 05, 2021 at 05:37:25PM +, Qing Zhao wrote:
> > On Nov 5, 2021, at 11:17 AM, Jakub Jelinek wrote:
> >
> > On Fri, Nov 05, 2021 at 04:11:36PM +, Qing Zhao wrote:
> >> 3076 if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE
> >> 3077 && tree_fits_uhwi_p (var_size)
>
> On Nov 5, 2021, at 11:17 AM, Jakub Jelinek wrote:
>
> On Fri, Nov 05, 2021 at 04:11:36PM +, Qing Zhao wrote:
>> 3076 if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE
>> 3077 && tree_fits_uhwi_p (var_size)
>> 3078 && (init_type == AUTO_INIT_PATTERN
>> 3079
On Fri, Nov 05, 2021 at 04:11:36PM +, Qing Zhao wrote:
> 3076 if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE
> 3077 && tree_fits_uhwi_p (var_size)
> 3078 && (init_type == AUTO_INIT_PATTERN
> 3079 || !is_gimple_reg_type (var_type))
> 3080 && int
Thanks all for the information.
Based on the information so far, my understanding is that we cannot revert
r12-979-g782e57f2c09
Since it’s for enabling YMM and ZMM registers to be used for by_pieces
operations on X86.
Let me know if I miss anything here.
FYI.
This issue was found during my wo
On Fri, Nov 5, 2021 at 3:01 AM Richard Biener
wrote:
>
> On Fri, Nov 5, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
> wrote:
> >
> > On Thu, Nov 04, 2021 at 11:05:35PM -0700, Andrew Pinski via Gcc-patches
> > wrote:
> > > > I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in
On Fri, Nov 5, 2021 at 7:54 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Nov 04, 2021 at 11:05:35PM -0700, Andrew Pinski via Gcc-patches wrote:
> > > I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in
> > > GCC11 and GCC12 (on the same X86 machine)
> > >
> > > For gcc11:
On Thu, Nov 04, 2021 at 11:05:35PM -0700, Andrew Pinski via Gcc-patches wrote:
> > I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> > and GCC12 (on the same X86 machine)
> >
> > For gcc11:
> >
> > wide int max elts =3
> >
> > For gcc12:
> >
> > wide int max elts =9
> >
On Thu, Nov 4, 2021 at 1:38 PM Qing Zhao via Gcc-patches
wrote:
>
> Hi,
>
> I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> and GCC12 (on the same X86 machine)
>
> For gcc11:
>
> wide int max elts =3
>
> For gcc12:
>
> wide int max elts =9
>
> Does anyone know what’s
Hi Qing,
on 2021/11/5 上午4:37, Qing Zhao via Gcc-patches wrote:
> Hi,
>
> I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11
> and GCC12 (on the same X86 machine)
>
> For gcc11:
>
> wide int max elts =3
>
> For gcc12:
>
> wide int max elts =9
>
> Does anyone know what
Hi,
I noticed that the macro “WIDE_INT_MAX_ELTS” has different values in GCC11 and
GCC12 (on the same X86 machine)
For gcc11:
wide int max elts =3
For gcc12:
wide int max elts =9
Does anyone know what’s the reason for this difference?
Thanks a lot for any help.
Qing
18 matches
Mail list logo
