guojiufu writes:
Hi,
In this patch, the default value of
param=max-unrolled-average-calls-x1 is '0', which means to unroll
a loop, there should be no call inside the body. Do I need to set the
default value to a bigger value (16?) for later tune? Biger value will
keep the behavior unchange
Hi,
This is a trivial patch to clean existing rs6000 test targets
p8 and p9+ with existing has_arch_pwr8 and has_arch_pwr9
target combination or only one of them. Not sure if it's a
good idea to tidy this, but send out for comments.
Bootstrapped/regtested on powerpc64le-linux-gnu P9.
Any commen
Hi Segher,
>> proc check_effective_target_vect_len_load_store { } {
>> -return 0
>> +return [expr { [check_effective_target_has_arch_pwr9] }]
>> }
>
> Why not just
>
> return check_effective_target_has_arch_pwr9;
>
> ? (Or lose at least two pairs of brackets if not all three :-) )
Thanks,
Feng
From: Feng Xue OS
Sent: Wednesday, August 19, 2020 5:17 PM
To: Richard Biener
Cc: gcc-patches@gcc.gnu.org; Marc Glisse
Subject: [PATCH V2] Add pattern for pointer-diff on addresses with same
base/offset (PR 94234)
As Richard's comment, this p
Hi Will,
Thanks for the review!
on 2020/9/1 上午1:13, will schmidt wrote:
> On Mon, 2020-08-31 at 14:43 +0800, Kewen.Lin via Gcc-patches wrote:
>> Hi,
>>
>> Power9 supports vector with length in bytes load/store, this patch
>> is to teach check_effective_target_vect_len_load_store to take it
>> and
PING^3
Hongyu Wang 于2020年8月4日周二 下午11:40写道：
>
> Kirill Yukhin 于2020年8月4日周二 下午10:47写道：
> >
> > Hello,
> >
> > On 06 июл 09:58, Hongyu Wang via Gcc-patches wrote:
> > > Hi:
> > >
> > > This patch is about to support Intel Advanced Matrix Extensions (AMX)
> > > which will be enabled in GLC.
> > >
>
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-2957-gbc62bfb0f43eeada02cb924e3cb5457a399b01c0.
gcc/analyzer/ChangeLog:
PR analyzer/96798
* region-model.cc (region_model::on_call_pre): Handle
BUILT_IN_MEMSET_CHK.
gcc/testsuite/ChangeL
Clean up this code in preparation for fixing PR analyzer/96798.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-2956-gee7bfbe5eb70a23bbf3a2cedfdcbd2ea1a20c3f2.
gcc/analyzer/ChangeLog:
* region-model.cc (region_model::on_call_pre): Gather handling of
PR analyzer/96860 reports an ICE inside CONSTRUCTOR-handling with
--param analyzer-max-svalue-depth=0 when attempting to build a
binding_map for the CONSTRUCTOR's values.
The issue is that when handling (index, value) pairs for initializing
an array, the index values for the elements exceeds the s
On 8/31/20 3:50 PM, Martin Sebor wrote:
On 8/31/20 4:51 AM, Christophe Lyon wrote:
Hi,
...
I pushed a small aarch64 patch as obvious:
2020-08-31 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/strcmpopt_6.c: Suppress
-Wstringop-overread.
(same as you added fo
On 8/31/20 4:51 AM, Christophe Lyon wrote:
Hi,
...
I pushed a small aarch64 patch as obvious:
2020-08-31 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/strcmpopt_6.c: Suppress -Wstringop-overread.
(same as you added for i386)
Thank you!
On arm, there is a
On 8/31/20 5:10 AM, Aldy Hernandez wrote:
On 8/31/20 10:33 AM, Richard Biener wrote:
On Mon, Aug 31, 2020 at 10:20 AM Aldy Hernandez wrote:
As discussed in the PR, the type of a switch operand may be different
than the type of the individual cases. This is causing us to attempt to
intersect
It's time to use 20 instead of 2a. Pushed.
commit 2330b0f89b6ac47cbb2253562a350eb1d121dd69
Author: Marek Polacek
Date: Mon Aug 31 16:30:51 2020 -0400
cxx-status: Use C++20 instead of C++2a.
diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html
index d942e7d3..e69
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-2953-g0d1b4edc5fff834e8f924b20dd021ded7a21d2d2.
gcc/analyzer/ChangeLog:
PR analyzer/96763
* store.cc (binding_map::apply_ctor_to_region): Handle RANGE_EXPR
by calling a new binding_map::a
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to master as r11-2952-gecdb93224c56189a129e97c556fe6b78e1b15a63.
gcc/analyzer/ChangeLog:
PR analyzer/96764
* region-model-manager.cc
(region_model_manager::maybe_fold_unaryop): Handle VIEW_CONVERT_EXPR.
On 8/28/20 12:45 PM, Patrick Palka wrote:
(Removing libstd...@gcc.gnu.org from CC list)
On Fri, 28 Aug 2020, Patrick Palka wrote:
In resolve_address_of_overloaded_function, currently only the second
pass over the overload set (which considers just the function templates
in the overload set) che
On 8/25/20 8:26 AM, Marek Polacek wrote:
On Mon, Aug 24, 2020 at 10:49:38PM -0400, Jason Merrill wrote:
On 8/24/20 5:44 PM, Marek Polacek wrote:
--- a/gcc/tree.c
+++ b/gcc/tree.c
@@ -2123,6 +2123,23 @@ build_constructor_from_list (tree type, tree vals)
return build_constructor (type, v);
Hi!
Just a note:
On Tue, Aug 25, 2020 at 08:46:55PM +0800, Kewen.Lin wrote:
> 1) Currently address_cost hook on rs6000 always return zero, but at least
> from Power7, pre_inc/pre_dec kind instructions are cracked, it means we
> have to take the address update into account (scalar normal operation
Hi!
On Mon, Aug 31, 2020 at 02:43:50PM +0800, Kewen.Lin wrote:
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -7066,7 +7066,7 @@ proc check_effective_target_vect_fully_masked { } {
> # @code{len_store} optabs.
>
> proc check_effective_target_ve
On Mon, 2020-08-31 at 14:43 +0800, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> Power9 supports vector with length in bytes load/store, this patch
> is to teach check_effective_target_vect_len_load_store to take it
> and its laters as effective vector with length targets.
>
> Also supplement the do
Hi!
On Mon, Aug 31, 2020 at 04:06:47AM -0500, Xiong Hu Luo wrote:
> vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
> to be insert, arg2 is the place to insert arg1 to arg0. This patch adds
> __builtin_vec_insert_v4si[v4sf,v2di,v2df,v8hi,v16qi] for vec_insert to
> not expa
In d8487c949ad5 (~GCC 4.9.0), MODE_PARTIAL_INT modes were changed from
having an unknown number of undefined bits, to having a known number of
undefined bits, however the documentation on using SUBREG expressions
with MODE_PARTIAL_INT modes was not updated to reflect this.
The attached patch updat
On Mon, 2020-08-31 at 04:06 -0500, Xiong Hu Luo via Gcc-patches wrote:
> vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
> to be insert, arg2 is the place to insert arg1 to arg0. This patch adds
> __builtin_vec_insert_v4si[v4sf,v2di,v2df,v8hi,v16qi] for vec_insert to
> not
On Tue, Aug 25, 2020 at 12:50:46PM +0200, Tobias Burnus wrote:
> OK for mainline?
Generally, you know Fortran FE much more than I do, so just a few random
comments.
> --- a/gcc/fortran/trans-openmp.c
> +++ b/gcc/fortran/trans-openmp.c
> @@ -355,6 +355,51 @@ gfc_has_alloc_comps (tree type, tree de
Will:
> That looks OK within this context.
>
> Are there any existing tests that use these named variations?
>
> Thanks,
> -Will
I was not able to find any test cases for these named builtins. I
fixed the other issues you mentioned in the message and patch below.
Carl Lov
Hi!
On Fri, Aug 28, 2020 at 08:08:05AM -0700, Carl Love wrote:
> The defines for vec_popcnt, bvec_popcnth, vec_popcntw, vec_popcntd in
> gcc/config/rs6000/altivec.h are not listed in the Power 64-Bi ELF V2
> ABI specification revision 1.4, May 10, 2017. They are not used by any
> of the regressio
Hi all!
Proposed patch to PR96870 - Class name on error message.
Patch tested only on x86_64-pc-linux-gnu.
Make the error message more intelligible for the average user.
Thank you very much.
Best regards,
José Rui
2020-8-21 José Rui Faustino de Sousa
gcc/fortran/ChangeLog:
On Mon, Aug 03, 2020 at 05:37:40PM +0200, Tobias Burnus wrote:
> It turned out that the omp_discover_declare_target_tgt_fn_r
> discovered all nodes – but as it tagged the C++ alias nodes
> and not the streamed-out nodes, no device function was created
> and one got link errors if offloading devices
On Fri, 2020-08-28 at 08:08 -0700, Carl Love wrote:
> GCC maintainers:
>
Hi,
> The defines for vec_popcnt, bvec_popcnth, vec_popcntw, vec_popcntd in
s/bvec/vec/
> gcc/config/rs6000/altivec.h are not listed in the Power 64-Bi ELF V2
> ABI specification revision 1.4, May 10, 2017. They are n
On Fri, 28 Aug 2020, Jakub Jelinek wrote:
> > As far as `-fexceptions' and `-fasynchronous-unwind-tables' are concerned
> > it aligns with my understanding, i.e. in this specific scenario we need
> > `-fasynchronous-unwind-tables' for libcalls (all of them) so that an
>
> -fasynchronous-unwin
Hi,
This patch fixes a couple of ICEs seen when compiling D source code for
a 16-bit target. The one I used for testing was xstormy16-elf.
In the lowering of `bt*' intrinsics, some integer constants had
mismatched types, and bitsize was set to the wrong value.
In base_vtable_offset, the base of
Implement `-mgprel', forcing `-mexplicit-relocs' whenever the option is
active due to the lack of GAS macro support for GP-relative addressing.
gcc/
* riscv/riscv-protos.h (riscv_symbol_type): Add SYMBOL_GPREL
enumeration constant.
* config/riscv/riscv.c (riscv_cl
Hi Andre,
On 8/31/20 12:55 PM, Andre Vehreschild wrote:
+gfc_is_unlimited_polymorphic_nonptr (tree type)
+ tree field = TYPE_FIELDS (type); /* _data */
+ if (!field)
^^^ here you don't . So theoretically this routine could match a type which
has a _len as its third field, but that is not a un
On Mon, Aug 31, 2020 at 11:10 AM Aldy Hernandez wrote:
>
>
>
> On 8/31/20 10:33 AM, Richard Biener wrote:
> > On Mon, Aug 31, 2020 at 10:20 AM Aldy Hernandez wrote:
> >>
> >> As discussed in the PR, the type of a switch operand may be different
> >> than the type of the individual cases. This is
On Mon, Aug 31, 2020 at 11:09 AM Xiong Hu Luo via Gcc-patches
wrote:
>
> vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
> to be insert, arg2 is the place to insert arg1 to arg0. This patch adds
> __builtin_vec_insert_v4si[v4sf,v2di,v2df,v8hi,v16qi] for vec_insert to
> not
On Mon, Aug 31, 2020 at 12:25 AM Richard Biener wrote:
>
> On Sat, 29 Aug 2020, sunil.k.pandey wrote:
>
> > On Linux/x86_64,
> >
> > dccbf1e2a6e544f71b4a5795f0c79015db019fc3 is the first bad commit
> > commit dccbf1e2a6e544f71b4a5795f0c79015db019fc3
> > Author: Richard Biener
> > Date: Mon Jul
This fixes SLP reduction of two-operator operations by marking those
not supported. In fact any live lane out of such an operation cannot
be code-generated correctly.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
This is for GCC 10 only, trunk gets the new testcase only.
Richar
>
> Yeah. Or even refactor the output machinery so that in theory
> we can create asm fragments [into memory] for functions and variables
> and only at the end concat/output them in a desired order (cf.
> -fno-toplevel-reorder
> wrt toporder code-generation we'd prefer). That would also be one
>
> All right, but let's start from the basic objective of the patch. Do
> we want to have something like ipa_call_arg_values?
OK, i suppose you patch was motivated by two things:
1) combine results of the estimates to one place (reducing number
of parameters in estimate_size_and_time) whi
> Hi,
>
> On Mon, Aug 31 2020, Feng Xue OS wrote:
> > This patch is to fix a bug that cost that is used to evaluate clone
> > candidate
> > becomes negative due to integer overflow.
> >
> > Feng
> > ---
> > 2020-08-31 Feng Xue
> >
> > gcc/
> > PR tree-optimization/96806
>
> the compon
Hi Tobias,
in (look for ^^^):
diff --git a/gcc/fortran/trans-openmp.c b/gcc/fortran/trans-openmp.c
index 063d4c145e2..705cdc7749f 100644
--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -355,6 +355,51 @@ gfc_has_alloc_comps (tree type, tree decl)
return false;
}
+/* Retur
Hi,
On Wed, 26 Aug 2020 at 22:36, Jeff Law via Gcc-patches
wrote:
>
> On Tue, 2020-06-23 at 20:05 -0600, Martin Sebor wrote:
> > -Wstringop-overflow is issued for both writing and reading past
> > the end, even though the latter problem is often viewed as being
> > lower severity than the former,
Hi Paul,
your patch looks fine to me. Ok for trunk.
Thanks for the patch.
Regards,
Andre
On Sat, 29 Aug 2020 12:50:20 +0100
Paul Richard Thomas via Fortran wrote:
> This patch detects a scalar function result that has allocatable components
> and is being used inside a scalarization l
On Thu, Aug 27, 2020 at 8:27 PM Giuliano Belinassi
wrote:
>
> Hi, Honza.
>
> Thank you for your detailed review!
>
> On 08/27, Jan Hubicka wrote:
> > > diff --git a/gcc/cgraph.c b/gcc/cgraph.c
> > > index c0b45795059..22405098dc5 100644
> > > --- a/gcc/cgraph.c
> > > +++ b/gcc/cgraph.c
> > > @@ -2
On Fri, Aug 21, 2020 at 12:00 AM Giuliano Belinassi
wrote:
>
> When using the LTO infrastructure to compile files in parallel, we
> can't simply use any of the LTO partitioner, once extra dependency
> analysis is required to ensure that some nodes are correctly
> partitioned together.
>
> Therefor
>>> the component is "ipa," please change that when you commit the patch.
>> Mistake has been made, I'v pushed it. Is there a way to correct it? git push
>> --force?
>
> There is. You need to wait until tomorrow (after the commit message
> gets copied to gcc/ChangeLog by a script) and then push a
Hi,
On Mon, Aug 31 2020, Feng Xue OS wrote:
>>> gcc/
>>> PR tree-optimization/96806
>
>> the component is "ipa," please change that when you commit the patch.
> Mistake has been made, I'v pushed it. Is there a way to correct it? git push
> --force?
There is. You need to wait until tomor
On 8/31/20 10:33 AM, Richard Biener wrote:
On Mon, Aug 31, 2020 at 10:20 AM Aldy Hernandez wrote:
As discussed in the PR, the type of a switch operand may be different
than the type of the individual cases. This is causing us to attempt to
intersect incompatible ranges.
This inconsistent
>> gcc/
>> PR tree-optimization/96806
> the component is "ipa," please change that when you commit the patch.
Mistake has been made, I'v pushed it. Is there a way to correct it? git push
--force?
Thanks,
Feng
vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value
to be insert, arg2 is the place to insert arg1 to arg0. This patch adds
__builtin_vec_insert_v4si[v4sf,v2di,v2df,v8hi,v16qi] for vec_insert to
not expand too early in gimple stage if arg2 is variable, to avoid generate
store h
Hi,
On Mon, Aug 31 2020, Feng Xue OS wrote:
> This patch is to fix a bug that cost that is used to evaluate clone candidate
> becomes negative due to integer overflow.
>
> Feng
> ---
> 2020-08-31 Feng Xue
>
> gcc/
> PR tree-optimization/96806
the component is "ipa," please change that
On Mon, Aug 31, 2020 at 10:39 AM Jakub Jelinek wrote:
>
> On Mon, Aug 31, 2020 at 10:33:20AM +0200, Richard Biener wrote:
> > In any case type mismatches here are of course unfortunate
> > and both more verification and documentation would be
> > nice. verify_gimple_switch only verifies all case
On Mon, Aug 31, 2020 at 10:33:20AM +0200, Richard Biener wrote:
> In any case type mismatches here are of course unfortunate
> and both more verification and documentation would be
> nice. verify_gimple_switch only verifies all case labels
> have the same type, the type of the switch argument is
>
On Mon, Aug 31, 2020 at 10:20 AM Aldy Hernandez wrote:
>
> As discussed in the PR, the type of a switch operand may be different
> than the type of the individual cases. This is causing us to attempt to
> intersect incompatible ranges.
>
> This inconsistent IL seems wrong to me, but it also seems
*PING* — For this part 1/n patch series.
On 8/25/20 12:50 PM, Tobias Burnus wrote:
This patch adds support for polymorphic variables ("CLASS")
to OpenMP's data-sharing clause FIRSTPRIVATE.
While the patch should be okay, there is more follow-up
work required, but one has to make a start :-)
*
On Mon, Aug 31, 2020 at 10:06 AM Feng Xue OS via Gcc-patches
wrote:
>
> This patch is to fix a bug that cost that is used to evaluate clone candidate
> becomes negative due to integer overflow.
OK.
Richard.
> Feng
> ---
> 2020-08-31 Feng Xue
>
> gcc/
> PR tree-optimization/96806
>
As discussed in the PR, the type of a switch operand may be different
than the type of the individual cases. This is causing us to attempt to
intersect incompatible ranges.
This inconsistent IL seems wrong to me, but it also seems pervasive
throughout GCC. Jason, as one of the original gimpl
On Sun, Aug 30, 2020 at 11:24 AM Jakub Jelinek wrote:
>
> On Fri, Aug 28, 2020 at 06:25:46PM +0200, Jakub Jelinek via Gcc-patches wrote:
> > You're right, thanks for spotting it, I've missed native_encode_rtx will do
> > quick_push rather than safe_push.
> >
> > Updated patch below, it shouldn't b
On Sat, Aug 29, 2020 at 1:31 PM Jan Hubicka wrote:
>
> >
> > It not only creates hidden symbols, but it also changes the original
> > symbol name to avoid clashses with other object files. It could be
> > very nice to avoid doing this at all.
> >
> > There was once an idea (I don't remember if fro
On Fri, Aug 28, 2020 at 10:04 PM Austin Morton wrote:
>
> > The patch misses documentation of the pragma.
>
> This was an intentional omission - when looking for documentation of
> the pragma in clang I found none.
>
> If we do want to document the pragmas in GCC:
> - what section of the document
This patch is to fix a bug that cost that is used to evaluate clone candidate
becomes negative due to integer overflow.
Feng
---
2020-08-31 Feng Xue
gcc/
PR tree-optimization/96806
* ipa-cp.c (decide_about_value): Use safe_add to avoid cost addition
overflow.
gcc/tests
On Fri, Aug 28, 2020 at 5:47 PM Ramana Radhakrishnan
wrote:
>
> On Wed, Aug 26, 2020 at 12:08 PM Richard Biener via Gcc-patches
> wrote:
> >
> > On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki wrote:
> > >
> > > Hi Kito,
> > >
> > > > I just found the mail thread about div mod with -fnon-call-
On Fri, Aug 28, 2020 at 4:18 PM Martin Liška wrote:
>
> Hey.
>
> The patch is about VEC_COND_EXP comparison of a SSA_NAME with a constant
> that is artifact of -fno-tree-ccp.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
Err, no - we shouldn
On Tue, Aug 11, 2020 at 05:43:48PM +0800, Hongtao Liu via Gcc-patches wrote:
> Hi:
> The issue is described in the bugzilla.
> Bootstrap is ok, regression test for i386/x86-64 backend is ok.
> Ok for trunk?
>
> ChangeLog
> gcc/
> PR target/96551
> * config/i386/sse.md (vec_unp
On Sat, 29 Aug 2020, sunil.k.pandey wrote:
> On Linux/x86_64,
>
> dccbf1e2a6e544f71b4a5795f0c79015db019fc3 is the first bad commit
> commit dccbf1e2a6e544f71b4a5795f0c79015db019fc3
> Author: Richard Biener
> Date: Mon Jul 6 16:26:50 2020 +0200
>
> tree-optimization/96075 - fix bogus misal
On Fri, 28 Aug 2020, Martin Jambor wrote:
> Hi,
>
> the testcase causes and ICE in the SRA verifier on x86_64 when
> compiling with -m32 because build_user_friendly_ref_for_offset looks
> at an out-of-bounds array_ref within an array_ref which accesses an
> offset which does not fit into a signed
66 matches
Mail list logo
