On 10/11/22 13:31, Palmer Dabbelt wrote:
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
Hi Christoph, Kito,
On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper
On Mon, Oct 10, 2022 at 11:07:06PM +, Joseph Myers wrote:
> On Mon, 10 Oct 2022, Paul Iannetta via Gcc-patches wrote:
>
> > I have a patch to bring this feature to the C front-end as well, and
> > would like to hear your opinion on it, especially since it may affect
> > the feature-set of the
On 10/11/22 18:17, Iain Sandoe wrote:
Hi Jason
On 11 Oct 2022, at 23:06, Jason Merrill wrote:
On 10/11/22 17:58, Iain Sandoe wrote:
Tested on x86_64-darwin19, OK for master?
thanks
Iain
-- >8 --
Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
is set properly on
On Tue, 11 Oct 2022 16:31:25 PDT (-0700), Vineet Gupta wrote:
On 10/11/22 13:46, Christoph Müllner wrote:
On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt wrote:
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
> Hi Christoph, Kito,
>
> On 5/5/21 12:36, Christoph
> -Original Message-
> From: Jakub Jelinek
> Sent: Tuesday, October 11, 2022 9:59 PM
> To: Liu, Hongtao
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH] [x86] Add define_insn_and_split to support general
> version of "kxnor".
>
> On Tue, Oct 11, 2022 at 04:03:16PM +0800, liuhongt
On 10/11/22 18:03, Paul Iannetta wrote:
Thank you very much for the comments.
On Mon, Oct 10, 2022 at 03:20:13PM -0400, Jason Merrill wrote:
On 10/9/22 12:12, Paul Iannetta wrote:
That's a nice feature! LLVM is using AS to mangle the
address-name qualified types but that would have required
Hi,
the recent optimization implemented for complex modes in:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595865.html
contains an oversight for big-endian platforms in the "interesting corner
case" mentioned in the message: it uses a lowpart SUBREG when the integer
modes have different
On 10/11/22 13:46, Christoph Müllner wrote:
On Tue, Oct 11, 2022 at 9:31 PM Palmer Dabbelt wrote:
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
> Hi Christoph, Kito,
>
> On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
>> This series provides a
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-c.cc: Add new line.
* config/riscv/riscv_vector.h (vwrite_csr): Add new line.
---
gcc/config/riscv/riscv-c.cc | 2 +-
gcc/config/riscv/riscv_vector.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git
This commit failed tests
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
FAIL: gcc.target/i386/pr92645.c scan-tree-dump-times optimized "vec_unpack_" 4
FAIL:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107226
On Wed, Oct 12, 2022 at 9:55 AM Hongtao Liu wrote:
>
> This commit failed tests
>
> FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
> FAIL: gcc.target/i386/pr101668.c scan-assembler vpmovsxdq
> FAIL: gcc.target/i386/pr101668.c
在 2022/10/12 上午4:57, Caroline Tice 写道:
I think that if VTV_PAGE_SIZE is not set to the actual size being used
by the system, it could result in some unexpected failures. I
believe the right thing to do in this case, since the size may vary,
is to get the actual size being used by the
Pushed to r13-3241
在 2022/9/27 下午10:01, David Malcolm 写道:
On Tue, 2022-09-27 at 14:02 +0800, Lulu Cheng wrote:
SARIF support was added in r13-967 but libvtv wasn't updated.
Sorry about breaking this. The patch looks reasonable to me, FWIW,
assuming that it fixes the issue, of
Hi Hontao,
This patch is to remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDS.
The new intel ISE removes AVX512_VP2INTERSECT from SAPPHIRERAPIDS,
AVX512_VP2INTERSECT is only supportted in Tigerlake.
Hi Uros,
This patch is to remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDS.
The new intel
Hi gcc-patches,
I had applied the patch below to binutils-gdb, but it recently got wiped
out by a gcc -> binutils-gdb configure.ac sync. Would it be possible to
apply it to the gcc repo so this doesn't happen again?
Thanks,
Simon
On 2022-03-15 17:26, Simon Marchi via Gdb-patches wrote:
>
Add a soft floating point condition to the register recovery part of the code.
libitm/ChangeLog:
* config/loongarch/sjlj.S: Add a soft floating point condition to the
register recovery part of the code.
---
libitm/config/loongarch/sjlj.S | 3 +++
1 file changed, 3 insertions(+)
> -Original Message-
> From: Cui, Lili
> Sent: Wednesday, October 12, 2022 11:00 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Liu, Hongtao ; ubiz...@gmail.com; Lu, Hongjiu
>
> Subject: [PATCH] Remove AVX512_VP2INTERSECT from PTA_SAPPHIRERAPIDS
>
> Hi Hontao,
>
> This patch is to remove
I would suggest we do not include those header files unless we really need that.
On Tue, Oct 11, 2022 at 2:32 PM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * config/riscv/riscv-vector-builtins.cc: Change include files same as
> ARM SVE.
> * config/riscv/t-riscv:
OK. I am gonna commit this with the following patches.
juzhe.zh...@rivai.ai
From: Kito Cheng
Date: 2022-10-12 11:39
To: juzhe.zhong
CC: gcc-patches
Subject: Re: [PATCH] RISC-V: Refine riscv-vector-builtins.o include files and
makefile.
I would suggest we do not include those header files
On 10/11/22 21:39, Kito Cheng via Gcc-patches wrote:
I would suggest we do not include those header files unless we really need that.
Agreed. Policy is to include what's needed. There's actually some
scripts that will identify extraneous header includes, but I don't
recall if we ever ran
On Tue, Oct 11, 2022 at 7:52 PM Lulu Cheng wrote:
>
> 在 2022/10/12 上午4:57, Caroline Tice 写道:
>
> I think that if VTV_PAGE_SIZE is not set to the actual size being used by
> the system, it could result in some unexpected failures. I believe the
> right thing to do in this case, since the size
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (GTY): Redefine vector types.
(build_const_pointer): New function.
(register_builtin_type): Ditto.
(DEF_RVV_TYPE): Simplify macro.
(register_vector_type): Refine implementation.
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.h: Remove redundant macro.
---
gcc/config/riscv/riscv-vector-builtins.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/gcc/config/riscv/riscv-vector-builtins.h
b/gcc/config/riscv/riscv-vector-builtins.h
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc: Change include files same as
ARM SVE.
* config/riscv/t-riscv: Refine makefile.
---
gcc/config/riscv/riscv-vector-builtins.cc | 9 +++--
gcc/config/riscv/t-riscv | 14
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.cc (add_vector_type_attribute):
Clang-format function.
---
gcc/config/riscv/riscv-vector-builtins.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Mon, Oct 10, 2022 at 4:23 PM Tom de Vries wrote:
>
> On 10/10/22 16:19, Thomas Schwinge wrote:
> > With that, OK to push?
>
> FWIW, nvptx change looks in the obvious category to me.
Can you rename the functions as default_asm_out_* and instead of
reviving dbxout.cc
put them into targhooks.cc?
On Mon, Oct 10, 2022 at 8:06 PM Arsen Arsenović via Gcc-patches
wrote:
>
> Evening,
>
> Ping on this patch, it should fix some configuration issues we get on
> ELF targets (especially in libstdc++).
>
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/602751.html
OK.
Thanks,
Richard.
>
From: Ju-Zhe Zhong
gcc/ChangeLog:
* config/riscv/riscv-vector-builtins.h (DEF_RVV_TYPE): Clang-format it.
---
gcc/config/riscv/riscv-vector-builtins.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/config/riscv/riscv-vector-builtins.h
On Mon, Oct 10, 2022 at 5:10 PM Jonathan Wakely wrote:
>
> On Mon, 10 Oct 2022 at 12:17, Jonathan Wakely wrote:
> >
> > On Mon, 10 Oct 2022 at 07:18, Richard Biener
> > wrote:
> > >
> > > On Fri, Oct 7, 2022 at 5:55 PM Jonathan Wakely via Gcc-patches
> > > wrote:
> > > >
> > > > This needs a
The testsuite needs a few tweaks following my patches to add multiple vector
sizes for amdgcn.
gcc/testsuite/ChangeLog:
* gcc.dg/pr104464.c: Xfail on amdgcn.
* gcc.dg/signbit-2.c: Likewise.
* gcc.dg/signbit-5.c: Likewise.
* gcc.dg/vect/bb-slp-68.c: Likewise.
Another example of the vectorizer needing explicit insns where the scalar
expander just works.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (neg2): New define_expand.
---
gcc/config/gcn/gcn-valu.md | 13 +
1 file changed, 13 insertions(+)
diff --git a/gcc/config/gcn/gcn-valu.md
On Tue, Oct 11, 2022 at 12:57 PM Jørgen Kvalsvik
wrote:
>
> On 07/10/2022 13:45, Jørgen Kvalsvik wrote:
> > On 07/10/2022 08:53, Richard Biener wrote:
> >> On Thu, Oct 6, 2022 at 4:28 PM Jørgen Kvalsvik
> >> wrote:
> >>>
> >>> On 06/10/2022 10:12, Richard Biener wrote:
> On Wed, Oct 5, 2022
The grammar for a lambda context can include 'M', and we
were adding the component that generated to the substitution table
twice. Just ignore the 'M' completely -- we'll already have done the
checks we need when we saw its predecessor. A prefix cannot be the
last component of a nested name,
On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva wrote:
>
> On Oct 10, 2022, Richard Biener wrote:
>
> > As noted in the Cauldron Discussion I think you should do all
> > instrumentation post-IPA only to simplify your life not needing to
> > handle inlining of instrumentation
>
> I looked a bit
On Thu, Jan 13, 2022 at 02:53:16PM +, Hafiz Abid Qadeer wrote:
> Currently we only make use of this directive when it is associated
> with an allocate statement.
Sorry for the delay.
I'll start with a comment that allocate directive in 5.0/5.1
for Fortran is a complete mess that has been
On Oct 11, 2022, Richard Biener wrote:
> On Tue, Oct 11, 2022 at 1:57 PM Alexandre Oliva wrote:
>>
>> On Oct 10, 2022, Richard Biener wrote:
>>
>> > As noted in the Cauldron Discussion I think you should do all
>> > instrumentation post-IPA only to simplify your life not needing to
>> >
Sure.
OK?
Aldy
On Tue, Oct 11, 2022 at 3:11 PM Andrew MacLeod wrote:
>
> It probably should just be changed to a print if it doesn't return..
> something like
>
> if (idx && res)
>{
> tracer.print (idx, "logical_combine produced");
> r.dump (dump_file);
> fputc ('\n',
On Tue, Oct 11, 2022 at 1:53 PM Andrew Stubbs wrote:
>
> On 11/10/2022 12:29, Richard Biener wrote:
> > On Tue, Oct 11, 2022 at 1:03 PM Andrew Stubbs wrote:
> >>
> >> This patch series adds additional vector sizes for the amdgcn backend.
> >>
> >> The hardware supports any arbitrary vector
The coverage support will under some conditions decide to split edges to
accurately report coverage. By running the test suite with/without this
edge splitting a small diff shows up, addressed by this patch, which
should catch future regressions.
Removing the edge splitting:
$ diff --git
Add a test to catch regression in line counts for labels on top of
then/else blocks. Only the 'goto ' should contribute to the line
counter for the label, not the if.
gcc/testsuite/ChangeLog:
* gcc.misc-tests/gcov-4.c:
---
gcc/testsuite/gcc.misc-tests/gcov-4.c | 26
It's incredibly annoying that some of the BRS_TRUE cases come after
BRS_FALSE, if only because we're not consistent. Having random
ordering increases the changes of thinkos when adapting the irange
code to floats.
gcc/ChangeLog:
* range-op.cc (operator_equal::op1_range): Move BRS_TRUE
Implementing ABS_EXPR allows us to fold certain __builtin_inf calls
since they are expanded into calls to involving ABS_EXPR.
This is an adaptation of the integer version.
gcc/ChangeLog:
* range-op-float.cc (class foperator_abs): New.
(floating_op_table::floating_op_table): Add
Most unordered comparisons can use the result from the ordered
version, if the operands are known not to be NAN or if the result is
true.
gcc/ChangeLog:
* range-op-float.cc (class foperator_unordered_lt): New.
(class foperator_relop_unknown): Remove
(class
On 11/10/2022 15:55, Michael Matz wrote:
> Hello,
>
> On Tue, 11 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
>
>> The coverage support will under some conditions decide to split edges to
>> accurately report coverage. By running the test suite with/without this
>> edge splitting a small
I forgot to mention. These were lifted from the integer counterparts.
Most of the code is the same, as the build_{cond} code in the frange
version will add the appropriate NAN (unless -ffinite-math-only), and
all we have to do is clear it on the false edge.
Aldy
On Tue, Oct 11, 2022 at 3:51 PM
On Tue, Oct 11, 2022 at 03:22:02PM +0200, Tobias Burnus wrote:
> Hi Jakub,
>
> On 11.10.22 14:24, Jakub Jelinek wrote:
>
> There is another issue besides what I wrote in my last review,
> and I'm afraid I don't know what to do about it, hoping Tobias
> has some ideas.
> The problem is that
On 11.10.22 16:15, Jakub Jelinek wrote:
I think the most common case is:
integer, allocatable :: var(:)
!$omp allocators allocator(my_alloc) ! must be in same scope as decl of 'var'
...
! optionally: deallocate(var)
end ! of scope: block/subroutine/... - automatic deallocation
So you talk
On Thu, Jan 13, 2022 at 02:53:17PM +, Hafiz Abid Qadeer wrote:
> gcc/fortran/ChangeLog:
>
> * trans-openmp.c (gfc_trans_omp_clauses): Handle OMP_LIST_ALLOCATOR.
> (gfc_trans_omp_allocate): New function.
> (gfc_trans_omp_directive): Handle EXEC_OMP_ALLOCATE.
>
>
在 2022-10-10 23:56, LIU Hao 写道:
在 2022-10-04 20:44, LIU Hao 写道:
Attached are revised patches. These are exported from trunk.
Revised further. The patch for libgfortran has been committed to trunk today, so I include only the
other two.
* In the second patch, a space character has been
Hi Jakub,
On 11.10.22 14:24, Jakub Jelinek wrote:
There is another issue besides what I wrote in my last review,
and I'm afraid I don't know what to do about it, hoping Tobias
has some ideas.
The problem is that without the allocate-stmt associated allocate directive,
Fortran allocatables are
Hello,
On Tue, 11 Oct 2022, Jørgen Kvalsvik wrote:
> I apologise for the confusion. The diff there is not a part of the
> change itself (note the indentation) but rather a way to reproduce,
Ah! Thanks, that explains it, sorry for adding confusion on top :-)
Ciao,
Michael.
On Oct 10, 2022, Richard Biener wrote:
> As noted in the Cauldron Discussion I think you should do all
> instrumentation post-IPA only to simplify your life not needing to
> handle inlining of instrumentation
I looked a bit into that after the Cauldron, and recalled why I wanted
to instrument
On Mon, Oct 10, 2022 at 11:19:24PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Mon, Oct 10, 2022 at 05:09:29PM -0400, Jason Merrill wrote:
> > On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote:
> > > My earlier patches gimplify the simplest non-side-effects assumptions
> > > into if
On Tue, Oct 11, 2022 at 04:03:16PM +0800, liuhongt via Gcc-patches wrote:
> gcc/ChangeLog:
>
> * config/i386/i386.md (*notxor_1): New post_reload
> define_insn_and_split.
> (*notxorqi_1): Ditto.
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -10826,6
On Tue, Oct 11, 2022 at 04:15:25PM +0200, Jakub Jelinek wrote:
> Well, it can use a weak symbol, if not linked against libgomp, the bit
> that it is OpenMP shouldn't be set and so realloc/free will be used
> and do
> if (arrdescr.gomp_alloced_bit)
> GOMP_free (arrdescr.data, 0);
> else
>
On Mon, Oct 10, 2022 at 17:04:09 -0400, Jason Merrill wrote:
> On 10/4/22 11:12, Ben Boeckel wrote:
> > This patch implements support for [P1689R5][] to communicate to a build
> > system the C++20 module dependencies to build systems so that they may
> > build `.gcm` files in the proper order.
>
On 11/10/2022 12:29, Richard Biener wrote:
On Tue, Oct 11, 2022 at 1:03 PM Andrew Stubbs wrote:
This patch series adds additional vector sizes for the amdgcn backend.
The hardware supports any arbitrary vector length up to 64-lanes via
masking, but GCC cannot (yet) make full use of them due
It probably should just be changed to a print if it doesn't return..
something like
if (idx && res)
{
tracer.print (idx, "logical_combine produced");
r.dump (dump_file);
fputc ('\n', dump_file);
}
Andrew
On 10/10/22 14:58, Aldy Hernandez wrote:
[Andrew, you OK with this? I
Hi!
The following patch implements excess precision support for C++.
Like for C, it uses EXCESS_PRECISION_EXPR tree to say that its operand
is evaluated in excess precision and what the semantic type of the
expression is.
In most places I've followed what the C FE does in similar spots, so
e.g.
gcc/ChangeLog:
* range-op-float.cc (foperator_unordered_le::op1_range): New.
(foperator_unordered_le::op2_range): New.
(foperator_unordered_gt::op1_range): New.
(foperator_unordered_gt::op2_range): New.
(foperator_unordered_ge::op1_range): New.
Hello,
On Tue, 11 Oct 2022, Jørgen Kvalsvik via Gcc-patches wrote:
> The coverage support will under some conditions decide to split edges to
> accurately report coverage. By running the test suite with/without this
> edge splitting a small diff shows up, addressed by this patch, which
> should
The following fixes an issue with how we handle epilogue generation
for SLP reductions of reduction paths where the actual live lanes
are not "canonical". We need to make sure to identify all live
lanes as reductions and thus have to iterate over all participating
SLP lanes when walking the
On Thu, Oct 6, 2022, 17:56 Jonathan Wakely wrote:
> > I actually just copy-pasted the header from another test, would it be
> simpler if i just removed it?
>
>
> Yes, that's probably the simplest solution, and then add a
> Signed-off-by: tag in your patch email, to state you're contributing
> it
On Mon, 2022-10-10 at 10:49 -0700, Caroline Tice via Gcc-patches wrote:
> Is "if (VTV_PAGE_SIZE != sysconf (_SC_PAGE_SIZE))" going to fail for
> loongarch?
Because LoongArch systems may have 4KB, 16KB, or 64KB pages.
> If not, why do you need to insert anything here at all? If so,
> perhaps you
For genereal_reg_operand, it will be splitted into xor + not.
For mask_reg_operand, it will be splitted with UNSPEC_MASK_OP just
like what we did for other logic operations.
The patch will optimize xor+not to kxnor when possible.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
Ok for trunk?
Hi, I apply this patch in RVV downstrean. Tested it with a lot of vector
benchmark. It overal has a greate performance gain.
Maybe the last thing to merge this patch is wait for Richard Sandiford test it
in ARM SVE?
By the way, would you mind sharing the case list that GCC failed to vectorize
On Fri, Oct 07, 2022 at 04:26:58PM +0200, Tobias Burnus wrote:
> libgomp/nvptx: Prepare for reverse-offload callback handling
>
> This patch adds a stub 'gomp_target_rev' in the host's target.c, which will
> later handle the reverse offload.
> For nvptx, it adds support for forwarding the offload
On Tue, Oct 04, 2022 at 21:12:03 +0200, Harald Anlauf wrote:
> Am 04.10.22 um 17:12 schrieb Ben Boeckel:
> > This patch implements support for [P1689R5][] to communicate to a build
> > system the C++20 module dependencies to build systems so that they may
> > build `.gcm` files in the proper
On Tue, Oct 11, 2022 at 1:03 PM Andrew Stubbs wrote:
>
> This patch series adds additional vector sizes for the amdgcn backend.
>
> The hardware supports any arbitrary vector length up to 64-lanes via
> masking, but GCC cannot (yet) make full use of them due to middle-end
> limitations. Adding
On Mon, Oct 10, 2022 at 4:12 PM Paul Iannetta via Gcc-patches
wrote:
>
> Hi,
>
> I am trying to bridge the gap between the extensions supported by the C
> and C++ front-ends. When it comes to vector extensions, C++ supports
> vectors in comparisons and within conditional expressions whereas the
Hi,
This patch modifies the help function which generates permute index for
vector byte reversion and generates permute index directly for little endian
targets. It saves one "xxlnor" instructions on P8 little endian targets as
the original process needs an "xxlnor" to calculate complement for
On 07/10/2022 13:45, Jørgen Kvalsvik wrote:
> On 07/10/2022 08:53, Richard Biener wrote:
>> On Thu, Oct 6, 2022 at 4:28 PM Jørgen Kvalsvik
>> wrote:
>>>
>>> On 06/10/2022 10:12, Richard Biener wrote:
On Wed, Oct 5, 2022 at 2:49 PM Martin Liška wrote:
>
> On 10/5/22 14:04, Jørgen
On Tue, Oct 11, 2022 at 1:06 PM Jonathan Wakely wrote:
>
> On Tue, 11 Oct 2022 at 07:41, Richard Biener
> wrote:
> >
> > On Mon, Oct 10, 2022 at 5:10 PM Jonathan Wakely wrote:
> > >
> > > On Mon, 10 Oct 2022 at 12:17, Jonathan Wakely wrote:
> > > >
> > > > On Mon, 10 Oct 2022 at 07:18,
Fixes the following clang warning:
gcc/gimple-range-op.cc:310:16: warning: 'fold_range' overrides a member
function but is not marked 'override' [-Winconsistent-missing-override]
gcc/ChangeLog:
* gimple-range-op.cc: Add override keyword.
---
gcc/gimple-range-op.cc | 2 +-
1 file
When solving 0 = _15 & 1, we calculate _15 as:
[irange] int [-INF, -2][0, +INF] NONZERO 0xfffe
The known value of _15 is [0, 1] NONZERO 0x1 which is intersected with
the above, yielding:
[0, 1] NONZERO 0x0
This eventually gets copied to a _Bool [0, 1] NONZERO 0x0.
This is
Richard Biener writes:
> On Mon, 10 Oct 2022, Andrew Stubbs wrote:
>> On 10/10/2022 12:03, Richard Biener wrote:
>> > The following picks up the prototype by Ju-Zhe Zhong for vectorizing
>> > first order recurrences. That solves two TSVC missed optimization PRs.
>> >
>> > There's a new scalar
On Tue, Oct 11, 2022 at 10:03 AM liuhongt wrote:
>
> For genereal_reg_operand, it will be splitted into xor + not.
> For mask_reg_operand, it will be splitted with UNSPEC_MASK_OP just
> like what we did for other logic operations.
>
> The patch will optimize xor+not to kxnor when possible.
>
>
> -Original Message-
> From: Christophe Lyon
> Sent: Monday, October 10, 2022 4:30 PM
> To: gcc-patches@gcc.gnu.org; Kyrylo Tkachov
> Subject: Re: [PATCH][GCC 12] arm: Fix constant immediates predicates and
> constraints for some MVE builtins
>
> ping^2 ?
>
>
> On 10/5/22 16:55,
On Tue, 11 Oct 2022 at 07:41, Richard Biener wrote:
>
> On Mon, Oct 10, 2022 at 5:10 PM Jonathan Wakely wrote:
> >
> > On Mon, 10 Oct 2022 at 12:17, Jonathan Wakely wrote:
> > >
> > > On Mon, 10 Oct 2022 at 07:18, Richard Biener
> > > wrote:
> > > >
> > > > On Fri, Oct 7, 2022 at 5:55 PM
On Tue, 11 Oct 2022, Jakub Jelinek wrote:
> So, does this mean one has to have gcc configured --with-arch=sm_70
> or later to make reverse offloading work (and then on the other
> side no support for older PTX arches at all)?
> If yes, I was kind of hoping we could arrange for it to be more
>
On Mon, 10 Oct 2022, Andrew Stubbs wrote:
> On 10/10/2022 12:03, Richard Biener wrote:
> > The following picks up the prototype by Ju-Zhe Zhong for vectorizing
> > first order recurrences. That solves two TSVC missed optimization PRs.
> >
> > There's a new scalar cycle def kind,
> On 10 Oct 2022, at 21:38, Jonathan Wakely wrote:
>
> On Mon, 10 Oct 2022 at 19:06, Olivier Hainque via Libstdc++
> wrote:
>>
>> Sorry, I forgot to cc libstdc++ on
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603182.html
>>
>> which includes a regen of
On Okt 10 2022, Marek Polacek via Gcc-patches wrote:
> diff --git a/gcc/testsuite/c-c++-common/pointer-to-fn1.c
> b/gcc/testsuite/c-c++-common/pointer-to-fn1.c
> new file mode 100644
> index 000..975885462e9
> --- /dev/null
> +++ b/gcc/testsuite/c-c++-common/pointer-to-fn1.c
> @@ -0,0
The vectors sizes are simulated using implicit masking, but they make life
easier for the autovectorizer and SLP passes.
gcc/ChangeLog:
* config/gcn/gcn-modes.def (VECTOR_MODE): Add new modes
V32QI, V32HI, V32SI, V32DI, V32TI, V32HF, V32SF, V32DF,
V16QI, V16HI, V16SI,
Implements vec_init when the input is a vector of smaller vectors, or of
vector MEM types, or a smaller vector duplicated several times.
gcc/ChangeLog:
* config/gcn/gcn-valu.md (vec_init): New.
* config/gcn/gcn.cc (GEN_VN): Add andvNsi3, subvNsi3.
(GEN_VNM): Add
This patch series adds additional vector sizes for the amdgcn backend.
The hardware supports any arbitrary vector length up to 64-lanes via
masking, but GCC cannot (yet) make full use of them due to middle-end
limitations. Adding smaller "virtual" vector sizes increases the
complexity of the
GET_MODE_NUNITS isn't a compile time constant, so we end up with many
impossible insns in the machine description. Adding MODE_VF allows the insns
to be eliminated completely.
gcc/ChangeLog:
* config/gcn/gcn-valu.md
(2): Use MODE_VF.
(2): Likewise.
*
Add vec_extract expanders for all valid pairs of vector types.
gcc/ChangeLog:
* config/gcn/gcn-protos.h (get_exec): Add prototypes for two variants.
* config/gcn/gcn-valu.md
(vec_extract): New define_expand.
* config/gcn/gcn.cc (get_exec): Export the existing
perfect.
On 10/11/22 10:08, Aldy Hernandez wrote:
Sure.
OK?
Aldy
On Tue, Oct 11, 2022 at 3:11 PM Andrew MacLeod wrote:
It probably should just be changed to a print if it doesn't return..
something like
if (idx && res)
{
tracer.print (idx, "logical_combine produced");
On Mon, 10 Oct 2022, Nathan Sidwell wrote:
> On 10/4/22 13:36, Patrick Palka wrote:
> > Here when lazily loading the binding for f at parse time from the
> > template g, processing_template_decl is set and thus the call to
> > note_vague_linkage_fn from module_state::read_cluster has no effect,
>
Hello, is there any update regarding the patch PR105387 for bug 105387? We've
been waiting for some time now, but the bugzilla bug is still open:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105387. If there is any issue with
the patch (besides the ones we discussed before), please let us know.
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the module purview:
if (data->hash->add_namespace_entities (decl, data->partitions))
{
/* It contains an exported
Hi
Now that pretty printer is fixed (once patch validated) I'd like to
propose this patch again.
Note that I'am adding a check on pretty printer with a std::any on
a std::wstring. I did so because of the FIXME in printers.py which is
dealing with 'std::string' explicitely. Looks
On 10/11/22 11:35, Patrick Palka wrote:
IIUC the function depset::hash::add_binding_entity has an assert
verifying that if a namespace contains an exported entity, then
the namespace must have been opened in the module purview:
if (data->hash->add_namespace_entities (decl, data->partitions))
On Tue, 11 Oct 2022 at 19:58, Jonathan Wakely wrote:
>
>
>
> On Tue, 11 Oct 2022, 19:38 David Edelsohn via Libstdc++,
> wrote:
>>
>> This patch seems to have broken bootstrap on AIX. It seems to assume
>> methods that aren't guaranteed to be defined.
>
>
>
> It doesn't use anything that wasn't
This test fails on non-i?86/x86_64 targets because on those targets
we get
error: '-fcf-protection=full' is not supported for this target
so this patch limits where the test is run.
Tested on x86_64-pc-linux-gnu, ok for trunk?
gcc/testsuite/ChangeLog:
*
On 10/11/22 10:58, Patrick Palka wrote:
On Mon, 10 Oct 2022, Nathan Sidwell wrote:
On 10/4/22 13:36, Patrick Palka wrote:
Here when lazily loading the binding for f at parse time from the
template g, processing_template_decl is set and thus the call to
note_vague_linkage_fn from
On Tue, 11 Oct 2022, 19:38 David Edelsohn via Libstdc++, <
libstd...@gcc.gnu.org> wrote:
> This patch seems to have broken bootstrap on AIX. It seems to assume
> methods that aren't guaranteed to be defined.
>
It doesn't use anything that wasn't already used by that file.
I have no idea how
Hi Christoph, Kito,
On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper fences for atomic load/store
* PR100266: Provide programmatic implementation of CAS
As both are very related, I
On Tue, 11 Oct 2022 12:06:27 PDT (-0700), Vineet Gupta wrote:
Hi Christoph, Kito,
On 5/5/21 12:36, Christoph Muellner via Gcc-patches wrote:
This series provides a cleanup of the current atomics implementation
of RISC-V:
* PR100265: Use proper fences for atomic load/store
* PR100266: Provide
1 - 100 of 123 matches
Mail list logo
