The first two arguments were "reversed", in that operand 0 was not
the output, but the input cc_reg. Remove operand 0 entirely, since
we can get the input cc_reg from within the operand 3 comparison
expression. This moves the output operand to index 0.
* config/aarch64/aarch64.md (@ccmpc
Return the entire comparison expression, not just the cc_reg.
This will allow the routine to adjust the comparison code as
needed for TImode comparisons.
Note that some users were passing e.g. EQ to aarch64_gen_compare_reg
and then using gen_rtx_NE. Pass the proper code in the first place.
Use ccmp to perform all TImode comparisons branchless.
* config/aarch64/aarch64.c (aarch64_gen_compare_reg): Expand all of
the comparisons for TImode, not just NE.
* config/aarch64/aarch64.md (cbranchti4, cstoreti4): New.
---
gcc/config/aarch64/aarch64.c | 182 +++
Currently we use %k to interpret an aarch64_cond_code value.
This interpretation is done via an array, aarch64_nzcv_codes.
The rtl is neither hindered nor harmed by using the proper
nzcv value itself, so index the array earlier than later.
This makes it easier to compare the rtl to the assembly.
I
Use xzr for the output when we only require the flags output.
This will be used shortly for TImode comparisons.
* config/aarch64/aarch64.md (ucmp3_carryinC): New.
(*ucmp3_carryinC_z1): New.
(*ucmp3_carryinC_z2): New.
(*ucmp3_carryinC): New.
---
gcc/config/aarch64/a
While cmp (extended register) and cmp (immediate) uses ,
cmp (shifted register) uses . So we can perform cmp xzr, x0.
For ccmp, we only have as an input.
* config/aarch64/aarch64.md (cmp): For operand 0, use
aarch64_reg_or_zero. Shuffle reg/reg to last alternative
and a
This is attacking case 3 of PR 94174.
The existing ccmp optimization happens at the gimple level,
which means that rtl expansion of TImode stuff cannot take
advantage. But we can to even better than the existing
ccmp optimization.
This expansion is similar size to our current branchful
expansio
Jiufu Guo writes:
Backported to GCC 9, preapproved by Segher.
Thanks,
Jiufu
> Segher Boessenkool writes:
>
>> Hi!
>>
>> On Thu, Mar 05, 2020 at 10:46:58AM +0800, Jiufu Guo wrote:
>>> PR93709 mentioned regressions on maxlocval_4.f90 and minlocval_f.f90 which
>>> relates to max of '-inf' and 'n
On 3/18/20 6:04 PM, Martin Sebor wrote:
On 3/16/20 3:10 PM, Jason Merrill wrote:
On 3/16/20 4:41 PM, Martin Sebor wrote:
The recent fix to avoid modifying in place the type argument in
handle_access_attribute (PR 92721) was incomplete and didn't fully
resolve the problem (an ICE in the C++ fron
On 3/12/20 6:38 PM, Martin Sebor wrote:
On 3/12/20 11:03 AM, Martin Sebor wrote:
On 3/11/20 3:30 PM, Martin Sebor wrote:
On 3/11/20 2:10 PM, Jason Merrill wrote:
On 3/11/20 12:57 PM, Martin Sebor wrote:
On 3/9/20 6:08 PM, Jason Merrill wrote:
On 3/9/20 5:39 PM, Martin Sebor wrote:
On 3/9/20
Jiufu Guo writes:
Hi!
I'd like to ping following patch. As near end of gcc10 stage 4, it seems
I would ask approval for GCC11 trunk.
Thanks,
Jiufu Guo
> Hi Honza and all,
>
> I updated the patch a little as below. Bootstrap and regtest are ok
> on powerpc64le.
>
> Is OK for trunk?
>
> Thanks f
Hi,
> -Original Message-
> From: Segher Boessenkool [mailto:seg...@kernel.crashing.org]
> Sent: Thursday, March 19, 2020 7:52 AM
> To: Yangfei (Felix)
> Cc: gcc-patches@gcc.gnu.org; Zhanghaijian (A)
> Subject: Re: [PATCH PR94026] combine missed opportunity to simplify
> comparisons with
On 3/18/20 1:04 PM, Jakub Jelinek wrote:
On Wed, Mar 18, 2020 at 12:57:18PM -0600, Martin Sebor via Gcc-patches wrote:
I noticed this last night:
https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html
Presumably that's the fix.
Or maybe for REAL_TYPE just care here about TYPE_MODE
On Tue, Mar 17, 2020 at 03:32:34PM +, Michael Matz wrote:
> On Mon, 16 Mar 2020, Richard Sandiford wrote:
> > Similarly for non-call exceptions on other statements. It sounds like
> > what you're describing requires the corresponding definition to happen
> > for memory outputs regardless of
On Wed, 18 Mar 2020, Jim Wilson wrote:
> > The new mnemonics have been supported by GAS for a little while now and
> > the old ones have been retained, however this is still a change that
> > breaks backwards compatibility. So I wonder if we shouldn't have an
> > autoconf test included for this
Hi!
On Tue, Mar 17, 2020 at 02:05:19AM +, Yangfei (Felix) wrote:
> > Trying 7 -> 8:
> > 7: r99:SI=r103:SI>>0x8
> > REG_DEAD r103:SI
> > 8: r100:SI=r99:SI&0x6
> > REG_DEAD r99:SI
> > Failed to match this instruction:
> > (set (reg:SI 100)
> > (and:SI (lshiftrt:SI (reg:SI
This attempts to make is_nothrow_constructible more robust (and
efficient to compile) by not depending on is_constructible. Instead the
__is_constructible intrinsic is used directly. The helper class
__is_nt_constructible_impl which checks whether the construction is
non-throwing now takes a bool t
Segher:
>
> Yes, but only for this fprnd vs. 2.06 (vsx) situation. Like we
> already
> have:
>
> if (TARGET_DIRECT_MOVE && !TARGET_VSX)
> {
> if (rs6000_isa_flags_explicit & OPTION_MASK_DIRECT_MOVE)
> error ("%qs requires %qs", "-mdirect-move", "-mvsx");
> rs6000_isa_f
On Tue, Mar 17, 2020 at 2:42 PM Maciej W. Rozycki wrote:
> On Tue, 18 Feb 2020, Kito Cheng wrote:
> > - fmv.x.s/fmv.s.x renamed to fmv.x.w/fmv.w.x in the latest RISC-V ISA
> >manual.
>
> The new mnemonics have been supported by GAS for a little while now and
> the old ones have been retained
On Wed, 18 Mar 2020, Martin Liška wrote:
> On 3/17/20 11:41 PM, Martin Sebor wrote:
> > The script reports errors by emitting them as #error directives into
> > standard output (so they cause the build to fail). Should this new
> > routine do the same thing? (/dev/stderr is also not available on
Andrea Corallo writes:
> Hi all,
>
> second version of the patch for the 200 characters limit for literal
> strings addressing comments.
>
> make check-jit is passing clean.
>
> Best Regards
> Andrea
>
> gcc/jit/ChangeLog
> 2020-??-?? Andrea Corallo
>
> * jit-playback.h
> (gcc::j
Hi all,
Updated version of the patch mainly addressing comments on the
concurrency issues.
I came to the conclusions that the caching should be done in the
function that we decide to be thread safe. However I haven't touched
parse_basever in any direction in the hope of having this still in
stag
On Wed, 18 Mar 2020, Jason Merrill wrote:
> On 3/18/20 11:58 AM, Patrick Palka wrote:
> > On Wed, 18 Mar 2020, Patrick Palka wrote:
> >
> > > On Tue, 17 Mar 2020, Jason Merrill wrote:
> > >
> > > > On 3/16/20 1:39 PM, Patrick Palka wrote:
> > > > > In this PR, we are performing constexpr evaluat
Ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-March/541962.html
On 3/12/20 4:38 PM, Martin Sebor wrote:
On 3/12/20 11:03 AM, Martin Sebor wrote:
On 3/11/20 3:30 PM, Martin Sebor wrote:
On 3/11/20 2:10 PM, Jason Merrill wrote:
On 3/11/20 12:57 PM, Martin Sebor wrote:
On 3/9/20 6:08 PM,
So I must have botched this when I hand-applied Richard's patch and use that to
generate a new one (I went back to his original and verified he got it right).
We had a test like
&& MEM_P (whatever)
ANd wanted to include regs ie
&& (MEM_P (whatever) || REG_P (whatever))
I added the latte
On 3/16/20 3:10 PM, Jason Merrill wrote:
On 3/16/20 4:41 PM, Martin Sebor wrote:
The recent fix to avoid modifying in place the type argument in
handle_access_attribute (PR 92721) was incomplete and didn't fully
resolve the problem (an ICE in the C++ front-end). The attached
patch removes the r
Hi!
On Sat, Mar 14, 2020 at 09:30:02AM +1030, Alan Modra wrote:
> On Fri, Mar 13, 2020 at 10:40:38AM -0500, Segher Boessenkool wrote:
> > > Using a call-saved register to cache a load out of the PLT looks
> > > really silly
> >
> > Who said anything about using call-saved registers? GCC will usu
On 3/5/20 2:51 AM, Jakub Jelinek wrote:
Hi!
As the testcases shows, the -Wconversion warning behaves quite differently
when -fsanitize=undefined vs. when not sanitizing, but in the end it is
not something specific to sanitizing, if a user uses
return static_cast(static_cast((d++, a) << 1U) |
On Tue, 2020-03-17 at 14:27 +0100, Christophe Lyon wrote:
>
> > Jeff pointed out off-list that using:
> >
> >N: ... /* { dg-error {...} } */
> > N+1: /* { dg-error {...} "" { target *-*-* } .-1 } */
> >
> > led to two identical test names for line N. This was causing the
> > results
On 3/12/20 2:10 PM, Jeff Law wrote:
On Mon, 2020-03-09 at 14:33 -0600, Martin Sebor wrote:
On 3/5/20 5:26 PM, Jeff Law wrote:
On Fri, 2020-02-14 at 15:41 -0700, Martin Sebor wrote:
Because attribute weakref introduces a kind of a definition, it can
only be applied to declarations of symbols th
On 3/18/20 11:58 AM, Patrick Palka wrote:
On Wed, 18 Mar 2020, Patrick Palka wrote:
On Tue, 17 Mar 2020, Jason Merrill wrote:
On 3/16/20 1:39 PM, Patrick Palka wrote:
In this PR, we are performing constexpr evaluation of a CONSTRUCTOR of type
union U which looks like
{.a=foo (&)}.
Sinc
On Wed, Mar 18, 2020 at 10:12:00PM +0800, Kewen.Lin wrote:
> > Btw, why not implement the neccessary vector init patterns?
>
> Power doesn't support 64bit vector size, it looks a bit hacky and
> confusing to introduce this kind of mode just for some optab requirement,
> but I admit the optab hack
Set /tmp first, then /var/tmp. /tmp is volatile on NetBSD and
/var/tmp not. This improves performance in the common use.
The downstream copy of GCC was patched for this preference
since 2015.
Remove occurence of /usr/tmp as it was never valid for NetBSD.
It was already activey disabled in the GCC
On March 18, 2020 6:20:29 PM GMT+01:00, Maxim Kuvyrkov
wrote:
>
>> On 17 Mar 2020, at 17:40, Richard Biener wrote:
>>
>>
>> This adds a missing type conversion to build_fold_addr_expr and
>adjusts
>> fallout - build_fold_addr_expr was used as a convenience to build an
>> ADDR_EXPR but some cal
On Wed, 18 Mar 2020, Patrick Palka wrote:
> When diagnosing a constraint error, we currently try to print the constraint
> inside a diagnostic constraint context with its template arguments substituted
> in. If substitution fails, then we instead just print the dependent
> form, as in the the tes
When diagnosing a constraint error, we currently try to print the constraint
inside a diagnostic constraint context with its template arguments substituted
in. If substitution fails, then we instead just print the dependent
form, as in the the test case below:
gcc/testsuite/g++.dg/concepts/diag
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 17:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][8/5x]: Remaining MVE store intrinsics which
> stores an half word, word and double word to memory.
>
> Hello Kyril
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 17:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][7/5x]: MVE store intrinsics which stores
> byte,half word or word to memory.
>
> Hello Kyrill,
>
> Following patc
On Wed, Mar 18, 2020 at 12:57:18PM -0600, Martin Sebor via Gcc-patches wrote:
> I noticed this last night:
>
> https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html
>
> Presumably that's the fix.
Or maybe for REAL_TYPE just care here about TYPE_MODE which should be all
that matters? I
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 17:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][6/5x]: Remaining MVE load intrinsics which
> loads half word and word or double word from memory.
>
> Hello Kyrill
On 3/18/20 8:30 AM, Jeff Law wrote:
On Wed, 2020-03-18 at 14:25 +, Szabolcs Nagy wrote:
The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote:
On 3/12/20 7:17 PM, Joseph Myers wrote:
On Thu, 5 Mar 2020, Martin Sebor wrote:
Tested on x86_64-linux. Is this acceptable for GCC 10? How a
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 17:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][5/5x]: MVE ACLE load intrinsics which load a
> byte, halfword, or word from memory.
>
> Hello Kyrill,
>
> Followi
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 17:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][4/5x]: MVE load intrinsics with zero(_z)
> suffix.
>
> Hello Kyrill,
>
> Following patch is the rebased version o
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 17:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][3/5x]: MVE store intrinsics with predicated
> suffix.
>
> Hello Kyrill,
>
> Following patch is the rebased versio
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 17:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][2/5x]: MVE load intrinsics.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
> (version v1) ht
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 17:18
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][1/5x]: MVE store intrinsics.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v1.
> (version v1) h
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534333.html
Hello,
This patch supports the following MVE ACLE load intrinsics with zero(_z)
suffix.
* ``_z`` (zero) which indicates false-predicated lanes are fi
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534354.html
Hello,
This patch supports the following Remaining MVE ACLE load intrinsics which load
an halfword,
word or double word from memory.
vldrdq_gather_
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534340.html
Hello,
This patch supports the following MVE ACLE store intrinsics which stores an
halfword,
word or double word to memory.
vstrdq_scatter_base_p_s
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534352.html
Hello,
This patch supports the following MVE ACLE load intrinsics which load a byte,
halfword,
or word from memory.
vld1q_s8, vld1q_s32, vld1q_s16,
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534335.html
Hello,
This patch supports the following MVE ACLE store intrinsics which stores a
byte, halfword,
or word to memory.
vst1q_f32, vst1q_f16, vst1q_s8
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534337.html
Hello,
This patch supports the following MVE ACLE store intrinsics with predicated
suffix.
vstrbq_p_s8, vstrbq_p_s32, vstrbq_p_s16, vstrbq_p_u8, vst
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534334.html
Hello,
This patch supports the following MVE ACLE store intrinsics.
vstrbq_scatter_offset_s8, vstrbq_scatter_offset_s32, vstrbq_scatter_offset_s16,
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534338.html
Hello,
This patch supports the following MVE ACLE load intrinsics.
vldrbq_gather_offset_u8, vldrbq_gather_offset_s8, vldrbq_s8, vldrbq_u8,
vldrbq_ga
> On 17 Mar 2020, at 17:40, Richard Biener wrote:
>
>
> This adds a missing type conversion to build_fold_addr_expr and adjusts
> fallout - build_fold_addr_expr was used as a convenience to build an
> ADDR_EXPR but some callers do not expect the result to be simplified
> to something else.
>
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 11:32
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][4/4x]: MVE intrinsics with quaternary
> operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 11:32
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][3/4x]: MVE intrinsics with quaternary
> operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 11:31
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][2/4x]: MVE intrinsics with quaternary
> operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 11:29
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v2][ARM][GCC][1/4x]: MVE intrinsics with quaternary
> operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 11:21
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v3][ARM][GCC][3/3x]: MVE intrinsics with ternary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v2.
Hi Srinath,
> -Original Message-
> From: Srinath Parvathaneni
> Sent: 18 March 2020 16:16
> To: gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov
> Subject: [PATCH v4][ARM][GCC][2/3x]: MVE intrinsics with ternary operands.
>
> Hello Kyrill,
>
> Following patch is the rebased version of v3.
Hello Kyrill,
Following patch is the rebased version of v3.
(version v3) https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542207.html
Hello,
This patch supports following MVE ACLE intrinsics with ternary operands.
vpselq_u8, vpselq_s8, vrev64q_m_u8, vqrdmlashq_n_u8, vqrdmlahq_n_u8,
vq
On Wed, 18 Mar 2020, Patrick Palka wrote:
> On Tue, 17 Mar 2020, Jason Merrill wrote:
>
> > On 3/16/20 1:39 PM, Patrick Palka wrote:
> > > In this PR, we are performing constexpr evaluation of a CONSTRUCTOR of
> > > type
> > > union U which looks like
> > >
> > >{.a=foo (&)}.
> > >
> > > S
Hi Michael, thanks for your response.
On 2020-03-17 16:32, Michael Matz wrote:
> Hello,
>
> On Mon, 16 Mar 2020, Richard Sandiford wrote:
>
>> Segher Boessenkool writes:
>>> On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote:
Segher Boessenkool writes:
>> we do delete "
The test case does the following:
igot = 1
!$acc parallel loop copy (igot, itmp)
do i = 1, N
!$acc atomic capture
iarr(i) = igot
igot = max (igot, i)
!$acc end atomic
end do
!$acc end parallel loop
And then checks that "all(iarr < N)". That works fine as l
On Wed, Mar 18, 2020 at 2:56 PM Kewen.Lin wrote:
>
> Hi Richi,
>
> Thanks for your comments.
>
> on 2020/3/18 下午6:39, Richard Biener wrote:
> > On Wed, Mar 18, 2020 at 11:06 AM Kewen.Lin wrote:
> >>
> >> Hi,
> >>
> >> As PR90332 shows, the current scalar epilogue peeling for gaps
> >> elimination
On Wed, 2020-03-18 at 14:25 +, Szabolcs Nagy wrote:
> The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote:
> > On 3/12/20 7:17 PM, Joseph Myers wrote:
> > > On Thu, 5 Mar 2020, Martin Sebor wrote:
> > >
> > > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
> > >
>
The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote:
> On 3/12/20 7:17 PM, Joseph Myers wrote:
> > On Thu, 5 Mar 2020, Martin Sebor wrote:
> >
> > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
> >
> > OK for GCC 10.
>
> Thank you. I committed it to trunk in r10-71
The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote:
> On 3/12/20 7:17 PM, Joseph Myers wrote:
> > On Thu, 5 Mar 2020, Martin Sebor wrote:
> >
> > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
> >
> > OK for GCC 10.
>
> Thank you. I committed it to trunk in r10-71
The previous implementation of summarized dumps within
region_model::dump_to_pp showed only the "top-level" keys within the
current frame and for globals, and thus didn't e.g. show the values
of fields of structs, or elements of arrays.
This patch rewrites it to gather a vec of representative path
PR analyzer/94047 reports an ICE, which turned out to be caused
by the erroneous use of TREE_TYPE on the view region's type
in region_model::get_representative_path_var that I introduced
in r10-7024-ge516294a1acb28d44cfd583cc6a80354044e and
fixed in g:787477a226033e36be3f6d16b71be13dd917e982.
tentative_region_model_context and test_region_model_context are both
forced to implement numerous pure virtual vfuncs of the abstract
region_model_context.
This patch adds a noop_region_model_context which provides empty
implementations of all of region_model_context's pure virtual functions,
and
I have followup work that touches this, so it's easiest to get this
cleanup in first.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as 0db2cd177020920e187ef47791d52cf689133a25.
gcc/analyzer/ChangeLog:
* engine.cc (exploded_node::exploded_node): Move imple
on 2020/3/18 下午6:40, Richard Biener wrote:
> On Wed, Mar 18, 2020 at 11:39 AM Richard Biener
> wrote:
>>
>> On Wed, Mar 18, 2020 at 11:06 AM Kewen.Lin wrote:
>>>
>>> Hi,
>>>
>>> As PR90332 shows, the current scalar epilogue peeling for gaps
>>> elimination requires expected vec_init optab with tw
Hi Richi,
Thanks for your comments.
on 2020/3/18 下午6:39, Richard Biener wrote:
> On Wed, Mar 18, 2020 at 11:06 AM Kewen.Lin wrote:
>>
>> Hi,
>>
>> As PR90332 shows, the current scalar epilogue peeling for gaps
>> elimination requires expected vec_init optab with two half size
>> vector mode. On
On Tue, 17 Mar 2020, Jason Merrill wrote:
> On 3/16/20 1:39 PM, Patrick Palka wrote:
> > In this PR, we are performing constexpr evaluation of a CONSTRUCTOR of type
> > union U which looks like
> >
> >{.a=foo (&)}.
> >
> > Since the function foo takes a reference to the CONSTRUCTOR we're bui
This patch fixes a problem which has existed for a long time, but showed
itself again after my previous patch to add conditional vector operators.
The solution is to set STORE_FLAG_VALUE properly. (More details in the
patch header.)
Andrew
amdgcn: Fix vector compare modes
The GCN VCC registe
Clang 9 supports C++20 via -std=c++2a but doesn't support three-way
comparisons, so fails to compile. When the compiler doesn't
support default comparisons, this patch defines operator== and
operator!= for the _Stop_state_ref class. That is enough for the header
to be compiled with Clang. It allo
This patch adds support for new conditional vector operators, including
cond_mult, and more modes for cond_add, cond_sub, cond_and, cond_ior and
cond_xor. This allows vectorization of more algorithms and several new
test passes.
The min and max operators remain on the to do list because those
Clang 9 supports C++20 via -std=c++2a but doesn't support Concepts, so
several of the new additions related to the Ranges library fail to
compile with -std=c++2a. The new definition of iterator_traits and the
definition of default_sentinel_t are guarded by __cpp_lib_concepts, so
check that in addit
This makes sure that the store a memset is folded to uses a type
covering all bits.
Bootstrapped / tested on x86_64-unknown-linux-gnu, pushed.
Richard.
2020-03-18 Richard Biener
PR middle-end/94206
* gimple-fold.c (gimple_fold_builtin_memset): Avoid using
partial i
Hi!
Another set of duplicated word fixes for things I've missed last time.
These include e.g. *.cc files I forgot about, or duplicated words at the start
or end of line.
Tested on x86_64-linux, committed to trunk as obvious.
2020-03-18 Jakub Jelinek
* asan.c (get_mem_refs_of_builtin_
"duanbo (C)" writes:
> Thank you for your suggestions. Looks like I have pasted the wrong test
> case. I'm sorry for that.
> I have modified accordingly and changed to use the correct test now in my new
> patch.
> I have carried a full test, no new failure witnessed. Newly added test fail
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534345.html
Hello,
This patch supports following MVE ACLE intrinsics with quaternary operands.
vabdq_m_f32, vabdq_m_f16, vaddq_m_f32, vaddq_m_f16, vaddq_m_n_f32
Hi Kyrill,
This patches was already committed.
I have resend this by mistake.
Sorry, please ignore this.
Regards
SRI.
From: Gcc-patches on behalf of Srinath
Parvathaneni
Sent: 18 March 2020 11:18
To: gcc-patches@gcc.gnu.org
Subject: [PATCH v3][ARM][GCC][1/3x]:
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534324.html
Hello,
This patch supports following MVE ACLE intrinsics with quaternary operands.
vmlaldavaq_p_s16, vmlaldavaq_p_s32, vmlaldavaq_p_u16, vmlaldavaq_p
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534339.html
Hello,
This patch supports following MVE ACLE intrinsics with quaternary operands.
vabdq_m_s8, vabdq_m_s32, vabdq_m_s16, vabdq_m_u8, vabdq_m_u32, va
Hello Kyrill,
Following patch is the rebased version of v1.
(version v1) https://gcc.gnu.org/pipermail/gcc-patches/2019-November/534332.html
Hello,
This patch supports following MVE ACLE intrinsics with quaternary operands.
vsriq_m_n_s8, vsubq_m_s8, vsubq_x_s8, vcvtq_m_n_f16_u16, vcvtq_x_
Due to a stupid mistake that I can't really explain, I'd got the
treatment of p12-p15 mixed up when adding support for the SVE PCS.
The registers are supposed to be call-preserved rather than
call-clobbered.
The fix is simple, but it has quite a big effect on the PCS tests
(as it should!).
Tested
Hello Kyrill,
Following patch is the rebased version of v2.
(version v2) https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542068.html
Hello,
This patch supports following MVE ACLE intrinsics with ternary operands.
vrmlaldavhaxq_s32, vrmlsldavhaq_s32, vrmlsldavhaxq_s32, vaddlvaq_p_s32,
Hello Kyrill,
Following patch is the rebased version of v2.
(version v2) https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542067.html
Hello,
This patch supports following MVE ACLE intrinsics with ternary operands.
vpselq_u8, vpselq_s8, vrev64q_m_u8, vqrdmlashq_n_u8, vqrdmlahq_n_u8,
v
Hello Kyrill,
Following patch is the rebased version of v2.
(version v2) https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542068.html
Hello,
This patch supports following MVE ACLE intrinsics with ternary operands.
vabavq_s8, vabavq_s16, vabavq_s32, vbicq_m_n_s16, vbicq_m_n_s32,
vbicq_
The two OpenACC firstprivate-mappings-1.{c,C} testcases use
long double, but not with nvidia – this also disables it for gcn.
Additionally, it moves the '#define DO_LONG_DOUBLE 0' to the
libgomp file (before it was in the included ../../gcc/testsuite file).
Committed as r10-7238-g4da9288745d8f9c
On Wed, Mar 18, 2020 at 11:39 AM Richard Biener
wrote:
>
> On Wed, Mar 18, 2020 at 11:06 AM Kewen.Lin wrote:
> >
> > Hi,
> >
> > As PR90332 shows, the current scalar epilogue peeling for gaps
> > elimination requires expected vec_init optab with two half size
> > vector mode. On Power, we don't
On Wed, Mar 18, 2020 at 11:06 AM Kewen.Lin wrote:
>
> Hi,
>
> As PR90332 shows, the current scalar epilogue peeling for gaps
> elimination requires expected vec_init optab with two half size
> vector mode. On Power, we don't support vector mode like V8QI,
> so can't support optab like vec_initv16
On 3/18/20 10:34 AM, Richard Biener wrote:
Yes, we don't really bump everytime we change something.
Fine, then please forget about the patch.
Martin
Hi,
As PR90332 shows, the current scalar epilogue peeling for gaps
elimination requires expected vec_init optab with two half size
vector mode. On Power, we don't support vector mode like V8QI,
so can't support optab like vec_initv16qiv8qi. But we want to
leverage existing scalar mode like DI t
On Wed, Mar 18, 2020 at 10:00 AM Martin Liška wrote:
>
> On 3/18/20 9:56 AM, Richard Biener wrote:
> > On Wed, Mar 18, 2020 at 9:54 AM Martin Liška wrote:
> >>
> >> Hi.
> >>
> >> I would like to bump LTO bytecode version for the upcoming GCC 10.1
> >> release.
> >>
> >> Ready for master?
> >
> >
Good Morning
We have attach our March order to this mail, confirm this order
by return mail and issue send Invoice Asap.
Thanks & Best Regards
May Lee
Know How International GmbH & Co. KG
Import
On 3/17/20 7:43 PM, Egeyar Bagcioglu wrote:
Hi Martin,
I like the patch. It definitely serves our purposes at Oracle and provides
another way to do what my previous patches did as well.
1) It keeps the backwards compatibility regarding -frecord-gcc-switches;
therefore, removes my related doub
1 - 100 of 106 matches
Mail list logo
