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 mat
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 last
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.
gcc/ChangeL
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
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 enu
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/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
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 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?
> >
> >
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 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
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 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
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
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_
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.
vrmlaldavhaxq_s32, vrmlsldavhaq_s32, vrmlsldavhaxq_s32, vaddlvaq_p_s32,
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 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_
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/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]:
"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
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_
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
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 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 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 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
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
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 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
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
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
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.
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
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
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?
> > >
>
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
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
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 "
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
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
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.
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 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: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: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: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
> 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.
>
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
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/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/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/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/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/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
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
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][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][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][5/5x]: MVE ACLE load intrinsics which load a
> byte, halfword, or word from memory.
>
> Hello Kyrill,
>
> Followi
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][6/5x]: Remaining MVE load intrinsics which
> loads half word and word or double word from memory.
>
> Hello Kyrill
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][7/5x]: MVE store intrinsics which stores
> byte,half word or word to memory.
>
> Hello Kyrill,
>
> Following patc
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
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
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
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
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 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
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 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 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/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) |
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/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
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
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,
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
1 - 100 of 106 matches
Mail list logo
