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++
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
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
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
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
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");
>
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
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
>
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
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
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
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
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
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
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
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 (&)}.
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
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
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:
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
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
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?
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
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
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,
>
>
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
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
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)
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)
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
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.
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.
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,
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/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,
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,
> 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
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
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
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
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,
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 (&)}.
> > >
> > >
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
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
> >>
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
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
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
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,
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
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
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 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
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
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
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
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
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
"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
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,
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
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,
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,
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,
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!).
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,
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,
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,
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
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
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
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
Hi Dennis,
> -Original Message-
> From: Dennis Zhang
> Sent: 12 March 2020 12:06
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; Richard Earnshaw ;
> Ramana Radhakrishnan ; Kyrylo Tkachov
>
> Subject: [PATCH][Arm][1/3] Support for Arm Custom Datapath Extension
> (CDE): enable the feature
>
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?
Um, is there any recent change warranting it?
The API extension reshuffles lto_section_type
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?
Um, is there any recent change warranting it? The version is already different
from GCC 9s and I'd rather wait until we're closer to
Hi.
I would like to bump LTO bytecode version for the upcoming GCC 10.1 release.
Ready for master?
Martin
>From b48f4187e11da79d1b0a932b1202f882defc Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Wed, 18 Mar 2020 09:40:24 +0100
Subject: [PATCH 3/3] Bump LTO bytecode version.
On 3/18/20 12:27 AM, Jan Hubicka wrote:
Hi.
There's updated version of the patch.
Changes from the previous version:
- comment added to ld_plugin_symbol
- new section renamed to ext_symtab
- assert added for loop iterations in produce_symtab and
produce_symtab_extension
Hi,
I hope this is
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 all
flavors of UNIX but I'm not sure how much that
98 matches
Mail list logo
