On Mon, 14 Aug 2023, Prathamesh Kulkarni wrote:
> On Mon, 7 Aug 2023 at 13:19, Richard Biener
> wrote:
> >
> > On Mon, Aug 7, 2023 at 2:05?AM Prathamesh Kulkarni via Gcc-patches
> > wrote:
> > >
> > > On Thu, 3 Aug 2023 at 17:48, Richard Biener wrote:
> > > >
> > > > On Thu, 3 Aug 2023, Richar
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...
> >>>
> >>> "Kewen.Lin" writes:
> Hi,
>
> Follo
On Tue, Aug 15, 2023 at 5:13 AM Kewen.Lin wrote:
>
> Hi,
>
> Commit r14-3093 introduced a random build failure on
> build/gencondmd.cc building. Since r14-3093 makes recog.h
> include tree.h, which further includes (depends on) some
> files that are generated during the building, such as:
> all-t
On 2023/08/15 12:38, Tsukasa OI wrote:
> On 2023/08/14 21:51, Jin Ma wrote:
>> Hi Tsukasa,
>> What a coincidence, I also implemented zfa extension, which also includes
>> fli related instructions :)
>
> Hi, I'm glad to know that someone is working on this extension more
> comprehensively (espec
From: Pan Li
This patch would like to support the rounding mode API for the
VFWCVT.X.F.V as the below samples.
* __riscv_vfwcvt_x_f_v_i64m2_rm
* __riscv_vfwcvt_x_f_v_i64m2_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(class vfwcvt_x_
On Sat, 5 Aug 2023 at 00:35, 钟居哲 wrote:
>
> >> Testing what specifically? Are you asking for correctness tests,
> >> performance/code quality tests?
>
> Add memcpy test using RVV instructions, just like we are adding testcases for
> auto-vectorization support.
I wanted to get in the test infras
The following uses the common find_loop_location as implemented
by the vectorizer to query a loop location also for unrolling.
That results in a more consistent reporting of locations.
Bootstrap / regtest pending on x86_64-unknown-linux-gnu.
* tree-ssa-loop-ivcanon.cc: Include tree-vector
Richard Biener writes:
> On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
>>
>> on 2023/8/14 22:16, Richard Sandiford wrote:
>> > No, it was more that 219-142=77, so it seems like a lot of lines
>> > are being duplicated rather than simply being moved. (Unlike for
>> > VMAT_LOAD_STORE_LANES, whi
Richard Biener writes:
> On Tue, 15 Aug 2023, Kewen.Lin wrote:
>
>> Hi Stefan,
>>
>> on 2023/8/15 02:51, Stefan Schulze Frielinghaus wrote:
>> > Hi everyone,
>> >
>> > I have bootstrapped and regtested the patch below on s390. For the
>> > 64-bit target I do not see any changes regarding the te
On Tue, 15 Aug 2023, Richard Sandiford wrote:
> Richard Biener writes:
> > On Tue, 15 Aug 2023, Kewen.Lin wrote:
> >
> >> Hi Stefan,
> >>
> >> on 2023/8/15 02:51, Stefan Schulze Frielinghaus wrote:
> >> > Hi everyone,
> >> >
> >> > I have bootstrapped and regtested the patch below on s390. For
Richard Biener writes:
> On Mon, 14 Aug 2023, Prathamesh Kulkarni wrote:
>> On Mon, 7 Aug 2023 at 13:19, Richard Biener
>> wrote:
>> > It doesn't seem to make a difference for x86. That said, the "fix" is
>> > probably sticking the correct target on the dump-check, it seems
>> > that vect_fold_
Richard Biener writes:
> On Tue, 15 Aug 2023, Richard Sandiford wrote:
>
>> Richard Biener writes:
>> > On Tue, 15 Aug 2023, Kewen.Lin wrote:
>> >
>> >> Hi Stefan,
>> >>
>> >> on 2023/8/15 02:51, Stefan Schulze Frielinghaus wrote:
>> >> > Hi everyone,
>> >> >
>> >> > I have bootstrapped and reg
On Tue, Aug 15, 2023 at 10:44 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Tue, Aug 15, 2023 at 4:44 AM Kewen.Lin wrote:
> >>
> >> on 2023/8/14 22:16, Richard Sandiford wrote:
> >> > No, it was more that 219-142=77, so it seems like a lot of lines
> >> > are being duplicated rat
From: Pan Li
This patch would like to support the rounding mode API for the
VFWCVT.X.F.V as the below samples.
* __riscv_vfwcvt_xu_f_v_u64m2_rm
* __riscv_vfwcvt_xu_f_v_u64m2_rm_m
Signed-off-by: Pan Li
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins-bases.cc
(vfwcvt_xu_frm
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 holding the patch up.
Richard
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.
Thanks.
juzhe.zh...@rivai.ai
From: Joern Rennecke
Date: 2023-08-15 16:12
To: 钟居哲
CC: Jeff Law; gcc-patches;
On 2023/08/15 12:38, Tsukasa OI wrote:
> > On 2023/08/14 21:51, Jin Ma wrote:
> >> Hi Tsukasa,
> >> What a coincidence, I also implemented zfa extension, which also
> >> includes fli related instructions :)
> >
> > Hi, I'm glad to know that someone is working on this extension more
> > comprehe
On Thu, 10 Aug 2023, Jeff Law wrote:
>
>
> On 8/10/23 09:05, Richard Biener wrote:
> >
> >
> >> Am 10.08.2023 um 17:01 schrieb Jeff Law via Gcc-patches
> >> :
> >>
> >>
> >>
> >>> On 8/10/23 06:41, Richard Biener via Gcc-patches wrote:
> >>> The following adjusts the heuristic when we perform
On Sun, 13 Aug 2023, Martin Jambor wrote:
> Hello Richi,
>
> it took me quite time to get back to this but it might have actually
> helped because it forced me to re-read the code around and in turn
> simplify the patch.
>
> On Mon, Jun 12 2023, Richard Biener wrote:
> > On Fri, 9 Jun 2023, Mart
On Mon, 14 Aug 2023, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong
>
> 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 *__
Julian Waters via Gcc-patches writes:
> Anyone?
Please see https://gcc.gnu.org/contribute.html#patches, specifically
the "Pinging patches, Getting patches applied" section.
Hi, Richi.
> + if (vect_store_lanes_supported (vectype, group_size, false)
> + == IFN_MASK_LEN_STORE_LANES)
>> can you use the previously computed 'ifn' here please?
Do you mean rewrite the codes as follows :?
internal_fn lanes_ifn = vect_store_lanes_supported (vectype, group_si
On 2023-08-15 01:59, Alexander Monakov wrote:
On Mon, 14 Aug 2023, Siddhesh Poyarekar wrote:
There's no practical (programmatic) way to do such validation; it has to be a
manual audit, which is why source code passed to the compiler has to be
*trusted*.
No, I do not think that is a logical c
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 implemented
include __builtin_{huge_valq
> Currently, autovec_length_operand predicate incorrect configuration is
> discovered in PR110989 since this following situation:
In case you haven't committed it yet: This is OK.
Regards
Robin
Please fix code style (this is the third time I say it and I'm really
frustrated now). GCC is a project, it's not a student homework so style
matters. And it's not so difficult to fix the style: for a new file you
can use "clang-format --style GNU -i filename.c" to do the work
automatically.
On
On 2023-08-14 19:12, Qing Zhao wrote:
Hi, Sid,
For the following testing case:
#include
#define noinline __attribute__((__noinline__))
static void noinline alloc_buf_more (int index)
{
struct annotated {
long foo;
char b;
char array[index];
long c;
} q, *p;
p =
On Tue, 15 Aug 2023, juzhe.zh...@rivai.ai wrote:
> Hi, Richi.
>
> > + if (vect_store_lanes_supported (vectype, group_size, false)
> > + == IFN_MASK_LEN_STORE_LANES)
>
> >> can you use the previously computed 'ifn' here please?
>
> Do you mean rewrite the codes as follows :?
>
> int
On Mon, 14 Aug 2023 at 18:23, Richard Sandiford
wrote:
>
> Prathamesh Kulkarni writes:
> > On Thu, 10 Aug 2023 at 21:27, Richard Sandiford
> > wrote:
> >>
> >> Prathamesh Kulkarni writes:
> >> >> static bool
> >> >> is_simple_vla_size (poly_uint64 size)
> >> >> {
> >> >> if (size.is_constant
> Plz put your testcases into:
>
> # widening operation only test on LMUL < 8
> set AUTOVEC_TEST_OPTS [list \
> {-ftree-vectorize -O3 --param riscv-autovec-lmul=m1} \
> {-ftree-vectorize -O3 --param riscv-autovec-lmul=m2} \
> {-ftree-vectorize -O3 --param riscv-autovec-lmul=m4} \
> {-ftree
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, &poffset,
- &alignment_support_scheme, &m
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
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 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
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 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,
>>
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 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,
>
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
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,
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
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 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/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
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
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
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
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 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
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 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
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 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
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
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
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
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
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
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/
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
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
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:
> 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.
>
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:
> 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
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 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
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 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
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
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
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
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
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
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
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
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/
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
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
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
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
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
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
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
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, 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
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, 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 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 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
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 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:
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
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
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
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
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, \
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
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
1 - 100 of 131 matches
Mail list logo
