Committed after fixing the comments.
https://gcc.gnu.org/g:a79cf858b39e01c80537bc5d47a5e9004418c267
Thanks
Gui Haochen
在 2023/8/14 15:47, Kewen.Lin 写道:
> Hi Haochen,
>
> on 2023/8/14 10:18, HAO CHEN GUI wrote:
>> Hi,
>> This patch modifies vsx extract expand and generates mfvsrwz/stxsiwx
>> f
Committed after tweaking and testing.
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d471bdb0453de7b738f49148b66d57cb5871937d
Thanks
Gui Haochen
在 2023/7/28 17:32, Kewen.Lin 写道:
> Hi Haochen,
>
> on 2023/7/5 11:22, HAO CHEN GUI wrote:
>> Hi,
>> This patch skips redundant vector extract insn to
From: Pan Li
This patch would like to support the rounding mode API for the
VFCVT.F.X.V and VFCVT.F.XU.V as the below samples.
* __riscv_vfcvt_f_x_v_f32m1_rm
* __riscv_vfcvt_f_x_v_f32m1_rm_m
* __riscv_vfcvt_f_xu_v_f32m1_rm
* __riscv_vfcvt_f_xu_v_f32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
"juzhe.zh...@rivai.ai" writes:
> Hi, Robin, Richard and Richi.
>
> I am wondering whether we can just simply replace the VEC_EXTRACT expander
> with binary?
>
> Like this :?
>
> DEF_INTERNAL_OPTAB_FN (VEC_EXTRACT, ECF_CONST | ECF_NOTHROW,
> - vec_extract, vec_extract)
> + vec_ex
LGTM
juzhe.zh...@rivai.ai
From: Robin Dapp
Date: 2023-08-15 23:49
To: gcc-patches; palmer; Kito Cheng; jeffreyalaw; juzhe.zh...@rivai.ai
CC: rdapp.gcc
Subject: [PATCH] RISC-V: Fix reduc_strict_run-1 test case.
Hi,
this patch changes the equality check for the reduc_strict_run-1
testcase from
From: Pan Li
This patch would like to support the rounding mode API for the
VFCVT.XU.F.V as the below samples.
* __riscv_vfcvt_xu_f_v_u32m1_rm
* __riscv_vfcvt_xu_f_v_u32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(BASE): New decl
Committed, thanks Jeff.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of juzhe.zh...@rivai.ai
Sent: Wednesday, August 16, 2023 9:23 AM
To: jeffreyalaw ; gcc-patches
Cc: kito.cheng ; Kito.cheng ;
Robin Dapp
Subject: Re: Re: [PATCH] RISC-V: Support MASK_LEN_{LOAD_LANES,STORE_LANES
Committed, thanks Richard.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Richard Biener via Gcc-patches
Sent: Tuesday, August 15, 2023 8:35 PM
To: Juzhe-Zhong
Cc: gcc-patches@gcc.gnu.org; richard.sandif...@arm.com
Subject: Re: [PATCH V2] VECT: Apply MASK_LEN_{LOAD_LANES, STORE_
Committed, thanks Kito.
Pan
From: Kito Cheng
Sent: Wednesday, August 16, 2023 1:57 PM
To: Li, Pan2
Cc: GCC Patches ; 钟居哲 ; Wang,
Yanzhang
Subject: Re: [PATCH v2] RISC-V: Support RVV VFCVT.X.F.V rounding mode intrinsic
API
LGTM
mailto:pan2...@intel.com>> 於 2023年8月16日 週三 13:17 寫道：
From: Pan
LGTM
於 2023年8月16日 週三 13:17 寫道：
> From: Pan Li
>
> This patch would like to support the rounding mode API for the
> VFCVT.X.F.V as the below samples.
>
> * __riscv_vfcvt_x_f_v_i32m1_rm
> * __riscv_vfcvt_x_f_v_i32m1_rm_m
>
> Signed-off-by: Pan Li
>
> gcc/ChangeLog:
>
> * config/riscv/ris
on 2023/8/16 10:31, Kewen.Lin via Gcc-patches wrote:
> Hi,
>
> As PR111021 shows, the below ${port}-protos.h include tree.h
> for code_helper and tree_code:
>
> arm/arm-protos.h:#include "tree.h"
> cris/cris-protos.h:#include "tree.h" (H-P removed this in r14-3218)
> microblaze/microblaze-
From: Pan Li
This patch would like to support the rounding mode API for the
VFCVT.X.F.V as the below samples.
* __riscv_vfcvt_x_f_v_i32m1_rm
* __riscv_vfcvt_x_f_v_i32m1_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(enum frm_op_type):
Hi Jeff,
Can you take a look at this little patch?
It's a bugfix patch that only affects the --apend
option that I added earlier, not anyone else.
And please let me know if there is a more
suitable reviewer as well. Thank you so much.
Best,
Lehua
-- Original ---
On 8/3/23 13:37, Mariam Harutyunyan via Gcc-patches wrote:
This patch adds CRC support for the RISC-V architecture. It adds internal
functions and built-ins specifically designed to handle CRC computations
efficiently.
If the target is ZBC, the clmul instruction is used for the CRC code
genera
On Jul 22, 2023, Fangrui Song wrote:
> I wonder whether this attribute can be named "alias" without arguments.
Erhm... Maybe I'm missing something about your suggestion, but without
arguments, how would we tell the compiler the symbol name of the
additional alias we want for the definition?
Ma
On 8/9/23 07:02, Paul Koning wrote:
On Aug 9, 2023, at 2:32 AM, Alexander Monakov wrote:
On Tue, 8 Aug 2023, Jeff Law wrote:
If the compiler can identify a CRC and collapse it down to a table or clmul,
that's a major win and such code does exist in the real world. That was the
whole po
On 8/9/23 00:32, Alexander Monakov wrote:
On Tue, 8 Aug 2023, Jeff Law wrote:
If the compiler can identify a CRC and collapse it down to a table or clmul,
that's a major win and such code does exist in the real world. That was the
whole point behind the Fedora experiment -- to determine if
Got it, thanks!
Will start with CVT and rest frm instructions first, and then refactor.
Pan
-Original Message-
From: Kito Cheng
Sent: Wednesday, August 16, 2023 11:44 AM
To: Li, Pan2
Cc: juzhe.zh...@rivai.ai; gcc-patches ; Wang, Yanzhang
Subject: Re: [PATCH v1] RISC-V: Support RVV V
I would prefer to introduce an enum template argument and refactor
existing code later :)
On Wed, Aug 16, 2023 at 11:40 AM Li, Pan2 via Gcc-patches
wrote:
>
> That should work as well, but may require some changes to existing codes like
> declaration, etc.
> I am OK for both the enum or inherit,
That should work as well, but may require some changes to existing codes like
declaration, etc.
I am OK for both the enum or inherit, and will start with the CVT parts, then
refactor the existing frm class.
Do you have any suggestion for the decision making?
Pan
-Original Message-
From
Or using an enum value rather than bool?
I am thinking we could also simplify/remove most other frm classes,
some practical example:
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 2074dac0f16..ace63e963a5 100644
--- a/gcc/conf
The implementation fails to handle this test case properly:
typedef double __attribute__((vector_size(32))) v4df;
void use1(double);
__attribute__((noipa)) double use(double)
{
register double x asm("f24") = 114.514;
__asm__("" : "+f" (x));
return x;
}
void test(void)
{
Thanks Kito for comments. How about leverage inherit instead of template?
AFAIK, the bool argument isn't recommended up to a point.
For example, as below to reuse the expand part.
class vfcvt_x : public function_base
{
public:
+ virtual bool has_rounding_mode_operand_p () const { return false
From: haochen.jiang
Sent: Tuesday, August 15, 2023 5:26 PM
To: rguent...@suse.de; gcc-regress...@gcc.gnu.org; gcc-patches@gcc.gnu.org;
Jiang, Haochen
Subject: [r14-2946 Regression] FAIL: gcc.target/i386/pr87007-5.c
scan-assembler-times vxorps[^\n\r]*xmm[0-9] 0 on Linux/x86_64
On Linux/x86_64,
From: haochen.jiang
Sent: Tuesday, August 15, 2023 5:26 PM
To: rguent...@suse.de; gcc-regress...@gcc.gnu.org; gcc-patches@gcc.gnu.org;
Jiang, Haochen
Subject: [r14-3148 Regression] FAIL: gcc.dg/vect/bb-slp-subgroups-2.c
scan-tree-dump-times slp2 "optimized: basic block" 2 on Linux/x86_64
On L
Hi,
As PR111021 shows, the below ${port}-protos.h include tree.h
for code_helper and tree_code:
arm/arm-protos.h:#include "tree.h"
cris/cris-protos.h:#include "tree.h" (H-P removed this in r14-3218)
microblaze/microblaze-protos.h:#include "tree.h"
rl78/rl78-protos.h:#include "tree.h"
s
On 8/15/23 19:21, juzhe.zh...@rivai.ai wrote:
For float/double, the in-order fold-left reduction produced the same
result as scalar codes.
But for _Float16 is not, I think the issue is not the reduction issue,
is float 16 precision issue.
But if it's a float16 precision issue then I would h
on 2023/8/15 17:13, Richard Sandiford wrote:
> Richard Biener writes:
>>> OK, fair enough. So the idea is: see where we end up and then try to
>>> improve/factor the APIs in a less peephole way?
>>
>> Yeah, I think that's the only good way forward.
>
> OK, no objection from me. Sorry for holdin
On Tue, Aug 8, 2023 at 3:23 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/avx10_1-vextractf64x2-1.c: New test.
> * gcc.target/i386/avx10_1-vextracti64x2-1.c: Ditto.
> * gcc.target/i386/avx10_1-vfpclasspd-1.c: Ditto.
> * g
On Tue, Aug 8, 2023 at 3:13 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * config/i386/driver-i386.cc (host_detect_local_cpu):
> Do not append -mno-avx10-max-512bit for -march=native.
> * common/config/i386/i386-common.cc
> (ix86_check_avx10_vector
On Tue, Aug 8, 2023 at 3:15 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * config/i386/driver-i386.cc (host_detect_local_cpu):
> Do not append -mno-avx10.1 for -march=native.
> * config/i386/i386-options.cc
> (ix86_check_avx10): New function to che
On Tue, Aug 8, 2023 at 3:16 PM Haochen Jiang via Gcc-patches
wrote:
>
> gcc/ChangeLog:
>
> * common/config/i386/cpuinfo.h (get_available_features):
> Add avx10_set and version and detect avx10.1.
> (cpu_indicator_init): Handle avx10.1-512.
> * common/config/i386/i38
gcc/ChangeLog:
* config/loongarch/t-loongarch: Add loongarch-driver.h into
TM_H. Add loongarch-def.h and loongarch-tune.h into
OPTIONS_H_EXTRA.
Co-authored-by: Lulu Cheng
---
gcc/config/loongarch/t-loongarch | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/con
This patch allow us auto-vectorize this following case:
#define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \
void __attribute__ ((noinline, noclone)) \
NAME##_8 (OUTTYPE *__restrict dest, INTYPE *__restrict src, \
Hi, Robin, Richard and Richi.
I am wondering whether we can just simply replace the VEC_EXTRACT expander with
binary?
Like this :?
DEF_INTERNAL_OPTAB_FN (VEC_EXTRACT, ECF_CONST | ECF_NOTHROW,
- vec_extract, vec_extract)
+ vec_extract, binary)
to fix the sign extend issue.
An
On 8/9/23 20:25, Tsukasa OI wrote:
From: Tsukasa OI
The "pause" RISC-V hint instruction requires the 'Zihintpause' extension
(in the assembler). However, GCC emits "pause" unconditionally, making
an assembler error while compiling code with __builtin_riscv_pause while
the 'Zihintpause' exte
Thanks Jeff.
I realize the quad_trunc/oct_trunc change is not necessary. I will remove that.
The middle-end support is approved, and testing on both X86 and ARM, soon will
be committed.
Will commit this patch after middle-end patch is committed.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
D
For float/double, the in-order fold-left reduction produced the same result as
scalar codes.
But for _Float16 is not, I think the issue is not the reduction issue, is float
16 precision issue.
Thanks.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2023-08-16 09:13
To: Robin Dapp; gcc-patches; p
On 8/15/23 09:49, Robin Dapp wrote:
Hi,
this patch changes the equality check for the reduc_strict_run-1
testcase from == to fabs () < EPS. The FAIL only occurs with
_Float16 but I'd argue approximate equality is preferable for all
float modes.
Regards
Robin
gcc/testsuite/ChangeLog:
This test passes since commit e41103081bfa "Fix undefined behaviour in
profile_count::differs_from_p", so remove the xfail annotation.
Tested on aarch64-linux-gnu, armv8l-linux-gnueabihf and x86_64-linux-gnu.
gcc/testsuite/ChangeLog:
* gcc.dg/unroll-7.c: Remove xfail.
---
gcc/testsuite/g
> On Aug 15, 2023, at 8:37 PM, Alexander Monakov wrote:
>
>> ...
>> At some point the system tools need to respect the programmer or operator.
>> There is a difference between writing "Hello, World" and writing
>> performance critical or safety critical code. That is the responsibility
>> of
On Tue, 15 Aug 2023, David Edelsohn wrote:
> > Making users responsible for verifying that sources are "safe" is not okay
> > (we cannot teach them how to do that since there's no general method).
> > Making users responsible for sandboxing the compiler is fine (there's
> > a range of sandboxing
On Tue, Aug 15, 2023 at 7:07 PM Alexander Monakov
wrote:
>
> On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
>
> > > Thanks, this is nicer (see notes below). My main concern is that we
> > > shouldn't pretend there's some method of verifying that arbitrary
> source
> > > code is "safe" to pass to
On Mon, 2023-08-14 at 09:26 -0400, Siddhesh Poyarekar wrote:
> Hi,
>
> Here's the updated draft of the top part of the security policy with all
> of the recommendations incorporated.
>
> Thanks,
> Sid
>
>
> What is a GCC security bug?
> ===
>
> A security bug is o
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
> > Thanks, this is nicer (see notes below). My main concern is that we
> > shouldn't pretend there's some method of verifying that arbitrary source
> > code is "safe" to pass to an unsandboxed compiler, nor should we push
> > the responsibility of
First, if this is no longer the appropriate group for this discussion,
please tell me where to send it.
I've been working to understand all the comments here. From them, I think:
1. It's OK to have gcc report back to the user whether each particular
call in tail position is optimized when -f
On Tue, Aug 15, 2023 at 3:46 PM David Malcolm wrote:
>
> On Tue, 2023-08-15 at 14:15 -0400, Lewis Hyatt wrote:
> > On Tue, Aug 15, 2023 at 12:15:15PM -0400, David Malcolm wrote:
> > > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > > > This patch enhances location_get_source_line(), whic
On Tue, 15 Aug 2023, chenxiaolong wrote:
> In the implementation process, the "q" suffix function is
> Re-register and associate the "__float128" type with the
> "long double" type so that the compiler can handle the
> corresponding function correctly. The functions i
Hi Jan-Benedict,
> On 15 Aug 2023, at 20:36, Jan-Benedict Glaw wrote:
> config-list.mk Darwin: Use --with-gnu-as for mass-building tests
>
> As `config-list.mk` is probably mostly used on Linux system, where
> Apple's tools aren't around. Let's use --with-gnu-as instead to have
> an useable as
Hi Jan-Benedict,
> config-list.mk Darwin: Use --with-gnu-as for mass-building tests
>
> As `config-list.mk` is probably mostly used on Linux system, where
> Apple's tools aren't around. Let's use --with-gnu-as instead to have
> an useable assembler.
>
> contrib/ChangeLog:
>
> * config-list.m
On Tue, 2023-08-15 at 14:15 -0400, Lewis Hyatt wrote:
> On Tue, Aug 15, 2023 at 12:15:15PM -0400, David Malcolm wrote:
> > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > > This patch enhances location_get_source_line(), which is the
> > > primary
> > > interface provided by the diagnosti
On Tue, 2023-08-15 at 13:58 -0400, Lewis Hyatt wrote:
> On Tue, Aug 15, 2023 at 11:43:05AM -0400, David Malcolm wrote:
> > On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > > Class file_cache_slot in input.cc is used to query specific lines
> > > of source
> > > code from a file when needed
Hi!
config-list.mk Darwin: Use --with-gnu-as for mass-building tests
As `config-list.mk` is probably mostly used on Linux system, where
Apple's tools aren't around. Let's use --with-gnu-as instead to have
an useable assembler.
contrib/ChangeLog:
* config-list.mk (i686-apple-darwin): Use
Hi!
i686-solaris2.11: Use --with-gnu-as for mass-building tests
As `config-list.mk` is probably mostly used on Linux system, where
Solaris's `as` isn't available, let's use GNU `as` as the default.
contrib/ChangeLog:
* config-list.mk (i686-solaris2.11): Use --with-gnu-as.
diff --git a/
On 2023-08-15 10:07, Alexander Monakov wrote:
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
Does this as the first paragraph address your concerns:
Thanks, this is nicer (see notes below). My main concern is that we shouldn't
pretend there's some method of verifying that arbitrary source co
OK.
Thanks!
> This define_insn is never used, since a sign-extend to the same mode is
> just a move, so delete it.
>
> Tested on x86_64-linux-gnu host for bpf-unknown-none target.
>
> gcc/
>
> * config/bpf/bpf.md (extendsisi2): Delete useless define_insn.
> ---
> gcc/config/bpf/bpf.md | 7
Hello David.
Thanks for the patch.
OK.
> In the BPF pseudo-c assembly dialect, registers treated as 32-bits
> rather than the full 64 in various instructions ought to be printed as
> "wN" rather than "rN". But bpf_print_register () was only doing this
> for specifically SImode registers, meani
This define_insn is never used, since a sign-extend to the same mode is
just a move, so delete it.
Tested on x86_64-linux-gnu host for bpf-unknown-none target.
gcc/
* config/bpf/bpf.md (extendsisi2): Delete useless define_insn.
---
gcc/config/bpf/bpf.md | 7 ---
1 file changed, 7 de
In the BPF pseudo-c assembly dialect, registers treated as 32-bits
rather than the full 64 in various instructions ought to be printed as
"wN" rather than "rN". But bpf_print_register () was only doing this
for specifically SImode registers, meaning smaller modes were printed
incorrectly.
This ca
From: benjamin priour
Yet another blunder.
Succesfully regstrapped against ce8cdf5bcf96a2db6d7b9f656fc9ba58d7942a83
on x86_64-linux-gnu.
OK to push on trunk ?
Sorry,
Benjamin.
Fixup below.
---
Test case g++.dg/analyzer/fanalyzer-show-events-in-system-headers.C
introduced by patch ce8cdf5bcf96
This patch is a modification of
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610115.html
following the discussion on
https://github.com/riscv-non-isa/riscv-c-api-doc/issues/32
Distinguish between explicit -mstrict-align and cpu tune param
for slow_unaligned_access=true/false.
Tested f
On Tue, Aug 15, 2023 at 12:15:15PM -0400, David Malcolm wrote:
> On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > This patch enhances location_get_source_line(), which is the primary
> > interface provided by the diagnostics infrastructure to obtain the line of
> > source code correspondin
On Tue, Aug 15, 2023 at 11:43:05AM -0400, David Malcolm wrote:
> On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > Class file_cache_slot in input.cc is used to query specific lines of source
> > code from a file when needed by diagnostics infrastructure. This will be
> > extended in a subse
On Tue, Aug 15, 2023 at 01:04:04PM -0400, David Malcolm wrote:
> On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> > The diagnostics routines for SARIF output need to read the source code back
> > in, so that they can generate "snippet" and "content" records, so they need
> > to
> > be able
Hi,
Is it ok to backport small unrisky features to the old gcc 11 branch ?
Here is a proposal to merge the ld.mold linker support which Martin has
pushed in gcc >= 12. It's a cherry-pick of commit
ad964f7eaef9c03ce68a01cfdd7fde9d56524868. Note that it doesn't backport
the gcc build machinery to be
On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> The diagnostics routines for SARIF output need to read the source code back
> in, so that they can generate "snippet" and "content" records, so they need to
> be able to cope with generated data locations. Add support for that in
> diagnostic
On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> Previous patches in this series have laid the groundwork for supporting
> source code locations in memory ("generated data") rather than ordinary
> files. This patch completes the support by adding awareness of such
> locations to all places t
On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> Add selftests for the new capabilities in input.cc related to source code
> locations that are stored in memory rather than ordinary files.
>
> gcc/ChangeLog:
>
> * input.cc (temp_source_file::do_linemap_add): New function.
>
Hello,
Thiago Jung Bauermann writes:
> Commit 92d1425ca780 "c++: redundant targ coercion for var/alias tmpls"
> changed the compiler error message in this testcase from
>
> : In instantiation of 'void foo() [with T = int]':
> :14:11: required from here
> :8:22: error: 'int' is not a class, s
On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> This patch enhances location_get_source_line(), which is the primary
> interface provided by the diagnostics infrastructure to obtain the line of
> source code corresponding to a given location, so that it understands
> generated data location
v2: Add missing PROFILE feature flag.
This patch adds support for the Cortex-A720 CPU to GCC.
No regressions on aarch64-none-elf.
Ok for master?
gcc/ChangeLog:
* config/aarch64/aarch64-cores.def (AARCH64_CORE): Add Cortex-
A720 CPU.
* config/aarch64/aarch64-tune.md: Re
Hi,
this patch changes the equality check for the reduc_strict_run-1
testcase from == to fabs () < EPS. The FAIL only occurs with
_Float16 but I'd argue approximate equality is preferable for all
float modes.
Regards
Robin
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/reduc/
On Wed, 2023-08-09 at 18:14 -0400, Lewis Hyatt wrote:
> Class file_cache_slot in input.cc is used to query specific lines of source
> code from a file when needed by diagnostics infrastructure. This will be
> extended in a subsequent patch to support obtaining the source code from
> in-memory gener
Just a random idea came to my mind, maybe we could introduce one more
template argument to reduce those codes for rounding mode intrinsic
stuff?
example:
diff --git a/gcc/config/riscv/riscv-vector-builtins-bases.cc
b/gcc/config/riscv/riscv-vector-builtins-bases.cc
index 2074dac0f16..9cc60842a5b 1
Hello,
On Mon, Aug 14 2023, Harald Anlauf via Gcc-patches wrote:
> Hi Martin,
>
> Am 14.08.23 um 19:39 schrieb Martin Jambor:
>> Hello,
>>
>> this patch addresses an issue uncovered by the undefined behavior
>> sanitizer. In function resolve_structure_cons in resolve.cc there is
>> a test starti
Hi,
This patch fixes an ICE that is specific to the D front-end language
version in GDC 12.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32, committed
to releases/gcc-12.
The pr110959.d test case has also been committed to mainline to catch
the unlikely event of a regression.
Regard
Richard Biener writes:
> The following changes the gate to perform vectorization of BB reductions
> to use needs_fold_left_reduction_p which in turn requires handling
> TYPE_OVERFLOW_UNDEFINED types in the epilogue code generation by
> promoting any operations generated there to use unsigned arith
> On Aug 15, 2023, at 10:07 AM, Alexander Monakov wrote:
>
>
> On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
>
>> Does this as the first paragraph address your concerns:
>
> Thanks, this is nicer (see notes below). My main concern is that we shouldn't
> pretend there's some method of verif
Hi!
On 2023-08-01T23:35:16+0800, Chung-Lin Tang wrote:
> this is v2 of the patch for implementing the OpenACC 2.7 addition of
> default(none|present) support for data constructs.
Thanks!
> Instead of propagating an additional 'oacc_default_kind' for OpenACC,
> this patch does it in a more compl
On 8/14/23 06:15, Juzhe-Zhong wrote:
This patch is depending on middle-end support:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627305.html
This patch allow us auto-vectorize this following case:
#define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \
vo
On 8/14/23 06:15, Juzhe-Zhong wrote:
This patch is depending on middle-end support:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627305.html
This patch allow us auto-vectorize this following case:
#define TEST_LOOP(NAME, OUTTYPE, INTYPE, MASKTYPE) \
vo
Thanks.
I just filed a PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111030 to record
this issue and added you to the CC list.
Qing
> On Aug 15, 2023, at 6:57 AM, Siddhesh Poyarekar wrote:
>
> On 2023-08-14 19:12, Qing Zhao wrote:
>> Hi, Sid,
>> For the following testing case:
>> #include
>
On Tue, 15 Aug 2023, Siddhesh Poyarekar wrote:
> Does this as the first paragraph address your concerns:
Thanks, this is nicer (see notes below). My main concern is that we shouldn't
pretend there's some method of verifying that arbitrary source code is "safe"
to pass to an unsandboxed compiler
On 8/15/23 03:16, juzhe.zh...@rivai.ai wrote:
The new patch looks reasonable to me now. Thanks for fixing it.
Could you append testcase after finishing test infrastructure ?
I prefer this patch with testcase after infrastructure.
So let's call this an ACK, but ask that Joern not commit until
On 8/15/23 02:12, Joern Rennecke wrote:
It lacks the strength reduction of the opaque pattern version for -O3,
though. Would people also like to see that expanded into RTL? Or
should I just drop in the opaque pattern for that? Or not at all,
because everyone uses Superscalar Out-Of-Order e
Hi,
this patch fixes the case where vec_extract gets passed a promoted
subreg (e.g. from a return value). When such a subreg is the
destination of a vector extraction we create a separate pseudo
register and ensure that the necessary promotion is performed
afterwards.
Before this patch a sign-ex
Committed, thanks Robin.
Pan
-Original Message-
From: Gcc-patches On Behalf
Of Robin Dapp via Gcc-patches
Sent: Tuesday, August 15, 2023 6:43 PM
To: Juzhe-Zhong ; gcc-patches@gcc.gnu.org
Cc: rdapp@gmail.com; kito.ch...@sifive.com; kito.ch...@gmail.com;
jeffreya...@gmail.com
Subject
On 8/13/23 13:52, Philipp Tomsich wrote:
On Sat, 12 Aug 2023 at 01:31, Jeff Law via Gcc-patches
wrote:
On 8/9/23 16:39, Tsukasa OI wrote:
On 2023/08/10 5:05, Jeff Law wrote:
I'd tend to think we do not want to expose the intrinsic unless the
right extensions are enabled -- even though
On 8/11/23 18:20, Tsukasa OI wrote:
I'll not be able to attend that meeting due to Japanese religious events
around Aug 13-16 (it may not be impossible but at least difficult) but
look forward seeing that some conclusion is made.
No problem. We hold that meeting weekly to work through any
On 8/14/23 19:46, Joern Rennecke wrote:
On Fri, 4 Aug 2023 at 21:52, Jeff Law wrote:
diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index b4884a30872..e61110fa3ad 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -49,6 +49,7 @@
#include
On Mon, Aug 14, 2023 at 8:32 PM Jason Merrill wrote:
> I think you also want to check for ATTR_FLAG_TYPE_IN_PLACE.
> [...]
> > + propagate_class_warmth_attribute (t);
> Maybe call this in check_bases_and_members instead?
Yes, that is sensible. Done.
Thanks,
Javier
Signed-off-by: Javier Martine
The following changes the gate to perform vectorization of BB reductions
to use needs_fold_left_reduction_p which in turn requires handling
TYPE_OVERFLOW_UNDEFINED types in the epilogue code generation by
promoting any operations generated there to use unsigned arithmetic.
The following does this,
The following moves CONSTRUCTOR handling into the generic BB
vectorization roots handling, removing a special case and finally
renaming the function now consisting of more than just constructor
detection.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vect-slp.cc (vec
On Tue, 15 Aug 2023, Juzhe-Zhong wrote:
> Hi, Richard and Richi.
>
> This patch is adding MASK_LEN_{LOAD_LANES,STORE_LANES} support into
> vectorizer.
>
> Consider this simple case:
>
> void __attribute__ ((noinline, noclone))
> foo (int *__restrict a, int *__restrict b, int *__restrict c,
>
Hi, Richard and Richi.
This patch is adding MASK_LEN_{LOAD_LANES,STORE_LANES} support into vectorizer.
Consider this simple case:
void __attribute__ ((noinline, noclone))
foo (int *__restrict a, int *__restrict b, int *__restrict c,
int *__restrict d, int *__restrict e, int *__restrict
on 2023/8/15 20:07, Richard Biener wrote:
> On Tue, Aug 15, 2023 at 1:47 PM Kewen.Lin wrote:
>>
>> on 2023/8/15 15:53, Richard Biener wrote:
>>> On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
on 2023/8/14 22:16, Richard Sandiford wrote:
> "Kewen.Lin" writes:
>> Hi Richard,
>>
The following supports vectorizing BB reductions involving a
constant or an invariant.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
* tree-vectorizer.h (_slp_instance::remain_stmts): Change
to ...
(_slp_instance::remain_defs): ... this.
(SLP_INSTANC
On Tue, Aug 15, 2023 at 1:47 PM Kewen.Lin wrote:
>
> on 2023/8/15 15:53, Richard Biener wrote:
> > On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
> >>
> >> on 2023/8/14 22:16, Richard Sandiford wrote:
> >>> "Kewen.Lin" writes:
> Hi Richard,
>
> on 2023/8/14 20:20, Richard Sandif
On Tue, 15 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> I realize this code perform analysis for load/store
>
> + internal_fn lanes_ifn;
>if (!get_load_store_type (vinfo, stmt_info, vectype, slp_node, mask,
> vls_type,
> ncopies, &memory_access_type, &
on 2023/8/15 15:53, Richard Biener wrote:
> On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
>>
>> on 2023/8/14 22:16, Richard Sandiford wrote:
>>> "Kewen.Lin" writes:
Hi Richard,
on 2023/8/14 20:20, Richard Sandiford wrote:
> Thanks for the clean-ups. But...
>
> "Kewe
1 - 100 of 131 matches
Mail list logo
