On Wed, Jul 31, 2024 at 2:08 PM Kong, Lingling wrote:
>
> *add_4 and *adddi_4 are for shorter opcode from cmp to inc/dec or add
> $128.
>
> But NDD code is longer than the cmp code, so there is no need to support NDD.
>
>
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
>
> Ok for tr
Unlike most system registers, fpmr can be heavily written to in code that
exercises the fp8 functionality. That is because every fp8 instrinsic call
can potentially change the value of fpmr.
Rather than just use an unspec, we treat the fpmr system register like
all other registers and use a move o
The ACLE declares several helper types and functions to facilitate construction
of `fpm` arguments. These are available when one of the arm_neon.h, arm_sve.h,
or arm_sme.h headers is included. These helpers don't map to specific FP8
instructions and there's no expectation that they will produce a
This introduces the relevant flags to enable access to the fpmr register and
fp8 intrinsics, which will be added subsequently.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (fp8): New.
* config/aarch64/aarch64.h (TARGET_FP8): Likewise.
* doc/invoke.texi (
This series introduces initial flags and functionality for the fp8 feature.
Specifically, the following are added:
- functions that enable constructing valid fpm register values.
- support for the '+fp8' -march modifier.
- support for reading and writing the new system register FPMR (Floating Po
在 2024/7/29 下午3:59, Xi Ruoyao 写道:
In r15-1207 I was too stupid to realize we just need to relax
ins_zero_bitmask_operand to allow using bstrins for aligning, instead of
adding a new split. And, "> 12" in ins_zero_bitmask_operand also makes
no sense: it rejects bstrins for things like "x & ~4l"
*add_4 and *adddi_4 are for shorter opcode from cmp to inc/dec or add
$128.
But NDD code is longer than the cmp code, so there is no need to support NDD.
Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for trunk?
gcc/ChangeLog:
PR target/113744
* con
Ok for trunk?
---
htdocs/gcc-14/changes.html| 7 +++
htdocs/gcc-14/porting_to.html | 9 +
2 files changed, 16 insertions(+)
diff --git a/htdocs/gcc-14/changes.html b/htdocs/gcc-14/changes.html
index ca4cae0f..b023a4b9 100644
--- a/htdocs/gcc-14/changes.html
+++ b/htdocs/gcc-14/ch
在 2024/7/31 4:48, Jeff Law 写道:
On 7/28/24 9:24 PM, Jiawei wrote:
This patch adds support for RISC-V RVA23 and RVB23 Profiles[1],
which depend on the base RISC-V Profiles support[2].
[1]
https://github.com/riscv/riscv-profiles/releases/tag/rva23-v0.4-rvb23-v0.1-internal-review
[2] https://
Kindly ping.
Pan
-Original Message-
From: Li, Pan2
Sent: Tuesday, July 23, 2024 1:06 PM
To: gcc-patches@gcc.gnu.org
Cc: juzhe.zh...@rivai.ai; kito.ch...@gmail.com; jeffreya...@gmail.com;
rdapp@gmail.com; Li, Pan2
Subject: [PATCH v1] RISC-V: Implement the quad and oct .SAT_TRUNC fo
2024-07-31 03:10 Jeff Law wrote:
>
>
>
>On 7/28/24 7:58 PM, Xiao Zeng wrote:
>> gcc/testsuite/ChangeLog:
>>
>> * gcc.target/riscv/pr105314-rtl.c: Skip zicond.
>> * gcc.target/riscv/pr105314-rtl32.c: Dotto.
>> * gcc.target/riscv/pr105314.c: Dotto.
>Why do you want to ski
gcc/ChangeLog:
PR 116152
* config/riscv/riscv.cc (riscv_option_override): Add deprecation
warning.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-9.c: Add check for warning.
Signed-off-by: Patrick O'Neill
---
v2 ChangeLog:
Shorten message and split into warn
On 7/30/24 16:08, Andrew Pinski wrote:
On Tue, Jul 30, 2024 at 4:04 PM Patrick O'Neill wrote:
gcc/ChangeLog:
PR 116152
* config/riscv/riscv.cc (riscv_option_override): Add deprecation
warning.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-9.c: Add c
LGTM, although I thought for a few seconds whether to use sorry or
error, but I think we don't really feel sorry for that case, so just
error is fine :P
On Wed, Jul 31, 2024 at 5:33 AM Patrick O'Neill wrote:
>
> Also add a testcase for -mabi=lp64d where 'd' is required.
>
> gcc/ChangeLog:
>
>
On 7/30/24 3:08 PM, Jakub Jelinek wrote:
On Tue, Jul 30, 2024 at 03:03:39PM -0600, Jeff Law wrote:
The compilation of convert-bfp-6.c itself is identical between the older (where
it didn't fail) and newer (where it fails) builds, what has changed is libgcc.a.
In particular, what matters is li
On 7/29/24 5:32 PM, Patrick Palka wrote:
On Mon, 29 Jul 2024, Jakub Jelinek wrote:
On Fri, Jul 26, 2024 at 06:00:12PM -0400, Patrick Palka wrote:
On Fri, 26 Jul 2024, Jakub Jelinek wrote:
On Fri, Jul 26, 2024 at 04:42:36PM -0400, Patrick Palka wrote:
// P2963R3 - Ordering of constraints inv
On 7/30/24 10:17 AM, Carl Love wrote:
> I tried, I hope I got it right, with -m32t:
>
> /* { dg-do run { target power10_hw } } */
> /* { dg-do compile { target { ! power10_hw } } } */
> /* { dg-require-effective-target int128 } */
>
> This gives:
>
> # of unsupported tests 1
>
> The
On Tue, Jul 30, 2024 at 4:04 PM Patrick O'Neill wrote:
>
> gcc/ChangeLog:
>
> PR 116152
> * config/riscv/riscv.cc (riscv_option_override): Add deprecation
> warning.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/predef-9.c: Add check for warning.
>
> Signed-of
gcc/ChangeLog:
PR 116152
* config/riscv/riscv.cc (riscv_option_override): Add deprecation
warning.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/predef-9.c: Add check for warning.
Signed-off-by: Patrick O'Neill
---
Tested prior to adding link. Relying on precommit
On Tue, 30 Jul 2024 at 23:49, Giuseppe D'Angelo
wrote:
>
> Hello,
>
> On 30/07/2024 15:04, Jonathan Wakely wrote:
> > On Mon, 29 Jul 2024 at 21:58, Giuseppe D'Angelo wrote:
> >>
> >> Hi,
> >>
> >> And this is the corresponding change libstdc++.
> >
> > Thanks for the patch.
>
> Again, thanks for t
Hello,
On 30/07/2024 15:04, Jonathan Wakely wrote:
On Mon, 29 Jul 2024 at 21:58, Giuseppe D'Angelo wrote:
Hi,
And this is the corresponding change libstdc++.
Thanks for the patch.
Again, thanks for the guidance, should be all fixed.
--
Giuseppe D'Angelo
From 1ab6d37ea41ca6fa05074a3d3b26
On 29/07/2024 22:53, Giuseppe D'Angelo wrote:
Hi,
The attached patch is a stab at adding the necessary compiler builtin to
support std::is_virtual_base_of (P2985R0, approved for C++26). The name
of the builtin matches the one just merged into clang:
https://github.com/llvm/llvm-project/issues/9
On 7/30/24 5:56 PM, Marek Polacek wrote:
On Tue, Jul 30, 2024 at 05:38:37PM -0400, Jason Merrill wrote:
On 7/30/24 4:59 PM, Marek Polacek wrote:
On Mon, Jul 29, 2024 at 06:34:40PM -0400, Jason Merrill wrote:
On 7/29/24 4:18 PM, Marek Polacek wrote:
On Tue, Jul 23, 2024 at 05:18:52PM -0400, Ja
On Tue, 30 Jul 2024 at 22:54, Giuseppe D'Angelo
wrote:
>
> On 30/07/2024 15:27, Jonathan Wakely wrote:
> > On Tue, 30 Jul 2024 at 14:08, Jonathan Wakely wrote:
> >>
> >> On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
> >> wrote:
> >>>
> >>> Hello!
> >>>
> >>> The attached patch implements adds
On Tue, Jul 30, 2024 at 05:38:37PM -0400, Jason Merrill wrote:
> On 7/30/24 4:59 PM, Marek Polacek wrote:
> > On Mon, Jul 29, 2024 at 06:34:40PM -0400, Jason Merrill wrote:
> > > On 7/29/24 4:18 PM, Marek Polacek wrote:
> > > > On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote:
> > > >
On 30/07/2024 15:27, Jonathan Wakely wrote:
On Tue, 30 Jul 2024 at 14:08, Jonathan Wakely wrote:
On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
wrote:
Hello!
The attached patch implements adds support for P2591R5 in libstdc++
(concatenation of strings and string_views, approved in Tokyo f
Hi,
v4 of patch 2/2 fixes a small mistake in 3 testcases, by relaxing the
expected q0 as result register into q[0-9]+ to account for codegen
differences depending on if the test is compiled with
-mfloat-abi=softfp or -mfloat-abi=hard.
I repost patch 1/2 (already approved) so that Linaro CI can ap
This patch fixes a bug where the mode iterator for mve_vdup
should be MVE_VLD_ST instead of MVE_vecs: V2DI and V2DF (thus vdup.64)
are not supported by MVE.
2024-07-02 Jolen Li
Christophe Lyon
gcc/
* config/arm/mve.md (mve_vdup): Fix mode iterator.
---
gcc/config
On 7/30/24 4:59 PM, Marek Polacek wrote:
On Mon, Jul 29, 2024 at 06:34:40PM -0400, Jason Merrill wrote:
On 7/29/24 4:18 PM, Marek Polacek wrote:
On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote:
On 7/17/24 5:33 PM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gn
Also add a testcase for -mabi=lp64d where 'd' is required.
gcc/ChangeLog:
PR 116111
* config/riscv/riscv.cc (riscv_option_override):
gcc/testsuite/ChangeLog:
* gcc.target/riscv/arch-41.c: New test.
* gcc.target/riscv/pr116111.c: New test.
Signed-off-by: Patrick
On Linux/x86_64,
2b3533cd871f62923e7a4f06a826f37bf0f35c5c is the first bad commit
commit 2b3533cd871f62923e7a4f06a826f37bf0f35c5c
Author: Filip Kastl
Date: Tue Jul 30 18:40:29 2024 +0200
gimple ssa: Teach switch conversion to optimize powers of 2 switches
caused
FAIL: gcc.target/i386/swi
On Tue, Jul 30, 2024 at 03:03:39PM -0600, Jeff Law wrote:
> > > The compilation of convert-bfp-6.c itself is identical between the older
> > > (where
> > > it didn't fail) and newer (where it fails) builds, what has changed is
> > > libgcc.a.
> > > In particular, what matters is libgcc/bid_binary
On 7/19/24 11:37 AM, Richard Sandiford wrote:
In g:9d20529d94b23275885f380d155fe8671ab5353a, I'd extended
insn_propagation to handle simple cases of hard-reg mode punning.
The punned "to" value was created using simplify_subreg rather
than simplify_gen_subreg, on the basis that hard-coded subr
On 7/23/24 11:26 PM, Jiang, Haochen wrote:
-Original Message-
From: Jakub Jelinek
Sent: Wednesday, July 24, 2024 1:09 PM
To: Jiang, Haochen
Cc: j...@ventanamicro.com; gcc-regress...@gcc.gnu.org; gcc-
patc...@gcc.gnu.org
Subject: Re: [r15-2196 Regression] FAIL: c-c++-common/dfp/con
On Mon, Jul 29, 2024 at 06:34:40PM -0400, Jason Merrill wrote:
> On 7/29/24 4:18 PM, Marek Polacek wrote:
> > On Tue, Jul 23, 2024 at 05:18:52PM -0400, Jason Merrill wrote:
> > > On 7/17/24 5:33 PM, Marek Polacek wrote:
> > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> > >
> >
On 7/30/24 2:50 PM, Raphael Zinsly wrote:
On Tue, Jul 30, 2024 at 4:29 PM Jeff Law wrote:
...
You define:
+#define RISCV_STACK_CLASH_VECTOR_CFA_REGNUM (GP_TEMP_FIRST + 4)
Where:
#define GP_REG_FIRST 0
#define GP_TEMP_FIRST (GP_REG_FIRST + 5)
So RISCV_STACK_CLASH_VECTOR_CFA_REGNUM defined a
Hello world, hi Jakub,
I would like to PING the following patch.
It's essentially Julian's patch, except:
* It is rediffed (albeit it mostly applied cleanly).
* I replaced the omp_is_initial_device call by an
internal function (IFN_) such that it can be evaluated
at compile time. With -O1, t
On Tue, Jul 30, 2024 at 4:29 PM Jeff Law wrote:
>...
> You define:
> +#define RISCV_STACK_CLASH_VECTOR_CFA_REGNUM (GP_TEMP_FIRST + 4)
>
> Where:
> #define GP_REG_FIRST 0
> #define GP_TEMP_FIRST (GP_REG_FIRST + 5)
>
> So RISCV_STACK_CLASH_VECTOR_CFA_REGNUM defined as "9" which I think is
> "s1". T
On 7/28/24 4:41 PM, Mark Harmstone wrote:
Empty structs result in empty LF_FIELDLIST types, which are valid, but
we weren't accounting for this and assuming they had to contain
subtypes.
gcc/
* dwarf2codeview.cc (get_type_num_struct): Fix NULL pointer dereference.
OK
jeff
On 7/28/24 9:24 PM, Jiawei wrote:
This patch adds support for RISC-V RVA23 and RVB23 Profiles[1],
which depend on the base RISC-V Profiles support[2].
[1]
https://github.com/riscv/riscv-profiles/releases/tag/rva23-v0.4-rvb23-v0.1-internal-review
[2] https://gcc.gnu.org/pipermail/gcc-patches/
Hi Andre,
On 7/26/24 16:05, Andre Vieira (lists) wrote:
This patch refactors and fixes an issue where
arm_mve_dlstp_check_dec_counter
was making an assumption about the form of what a candidate for a dec_insn.
I think this lacks some verb? (eg what a candidate for a dec_insn
"is" or "
This fixes a testsuite regression seen on m68k after some of the recent
ext-dce changes. Ultimately Richard S and I have concluded the bug was
a latent issue in subreg simplification.
Essentially when simplifying something like
(set (target:M1) (subreg:M1 (subreg:M2 (reg:M1) 0) 0))
Where M
On 7/29/24 6:51 AM, Andrew Burgess wrote:
Thomas Schwinge writes:
Hi!
On 2024-02-10T17:26:01+, Andrew Burgess wrote:
--- a/libiberty/argv.c
+++ b/libiberty/argv.c
@@ -439,17 +442,8 @@ expandargv (int *argcp, char ***argvp)
}
/* Add a NUL terminator. */
buf
'dg-compile' is not a thing, replace it with 'dg-do compile'.
PR target/68015
PR c++/83979
* c-c++-common/goacc/loop-shape.c: Fix 'dg-compile' typo.
* g++.dg/pr83979.C: Likewise.
* g++.target/aarch64/sve/acle/general-c++/attributes_2.C: Likewise.
* g
On 7/29/24 8:52 AM, Raphael Zinsly wrote:
On Mon, Jul 29, 2024 at 11:20 AM Jeff Law wrote:
On 7/29/24 6:18 AM, Raphael Zinsly wrote:
On Fri, Jul 26, 2024 at 6:48 PM Jeff Law wrote:
On 7/24/24 12:00 PM, Raphael Moreira Zinsly wrote:
Adds basic support to vector stack-clash protectio
On 7/30/24 10:17 AM, Christoph Müllner wrote:
As documented in PR116131, we might end up with the following
INSN for rv32i_xtheadmemidx after th_memidx_I_c is applied:
(insn 18 14 0 2 (set (mem:SI (plus:SI (reg/f:SI 141)
(ashift:SI (subreg:SI (reg:DI 134 [ a.0_1 ]) 0)
Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* src/c++17/fs_ops.cc: Fix file name in comment.
---
libstdc++-v3/src/c++17/fs_ops.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libstdc++-v3/src/c++17/fs_ops.cc b/libstdc++-v3/src/c++17/fs_ops.cc
index 7ffdce677
On 7/28/24 7:58 PM, Xiao Zeng wrote:
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr105314-rtl.c: Skip zicond.
* gcc.target/riscv/pr105314-rtl32.c: Dotto.
* gcc.target/riscv/pr105314.c: Dotto.
Why do you want to skip zicond for this test?
Jeff
> On 30 Jul 2024, at 19:01, Andi Kleen wrote:
>
> External email: Use caution opening links or attachments
>
>
>> Is that from some kind of rigorous measurement under perf? As you
>> surely know, 0.6% wall-clock time can be from boost clock variation
>> or just run-to-run noise on x86.
>
>
> > +BOOT_CFLAGS := -march=native -mtune=native $(BOOT_CFLAGS)
>
> I was under the impression that -mtune=native is useless with
> -march=native. Is that wrong?
On x86 it's right, but not sure about other architectures. I suppose
it doesn't hurt.
-Andi
PR target/51492
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr51492.c: New test.
Tested on x86_64-linux-gnu {,-m32}.
Uros.
diff --git a/gcc/testsuite/gcc.target/i386/pr51492.c
b/gcc/testsuite/gcc.target/i386/pr51492.c
new file mode 100644
index 000..0892e0c79a7
--- /dev/null
+++
Thanks! Committed
Edwin
On 7/29/2024 6:37 AM, Kito Cheng wrote:
LGTM, although I said no binutils check for zacas and zabha, but B is
a different situation since GCC will add that if zba, zbb and zbs are
all present.
On Thu, Jul 25, 2024 at 7:51 AM Edwin Lu wrote:
Binutils 2.42 and before
Andi Kleen writes:
> From: Andi Kleen
>
> ... that uses -march=native -mtune=native to build a compiler optimized
> for the host.
>
I like the idea and I'll probably use this. (I can't approve it though.)
> config/ChangeLog:
>
> * bootstrap-native.mk: New file.
>
> gcc/ChangeLog:
>
>
> Am 30.07.2024 um 19:22 schrieb Alexander Monakov :
>
>
> On Tue, 30 Jul 2024, Andi Kleen wrote:
>>> I have looked at this code before. When AVX2 is available, so is SSSE3,
>>> and then a much more efficient approach is available: instead of comparing
>>> against \r \n \\ ? one-by-one, build
Richard Biener wrote:
On Mon, Jul 29, 2024 at 9:26 PM Tobias Burnus wrote:
Inside pass_omp_target_link::execute, there is a call to
gimple_regimplify_operands but the value expression is not
expanded.[...]
Where is_gimple_mem_ref_addr is defined as:
/* Return true if T is a valid address oper
On Tue, 30 Jul 2024, Andi Kleen wrote:
> > I have looked at this code before. When AVX2 is available, so is SSSE3,
> > and then a much more efficient approach is available: instead of comparing
> > against \r \n \\ ? one-by-one, build a vector
> >
> > 0 1 2 3 4 5 6 7 8 9a bc
PR middle-end/54400
PR target/98161
* gcc.dg/vect/bb-slp-layout-18.c: Fix whitespace in dg directive.
* gcc.dg/vect/bb-slp-pr54400.c: Likewise.
* gcc.target/i386/pr98161.c: Likewise.
---
Committed as obvious.
gcc/testsuite/gcc.dg/vect/bb-slp-layout-18.c | 2
On Tue, Jul 30, 2024 at 3:00 PM Richard Biener wrote:
>
> On Tue, 30 Jul 2024, Alexander Monakov wrote:
>
> >
> > On Tue, 30 Jul 2024, Richard Biener wrote:
> >
> > > > Oh, and please add a small comment why we don't use XFmode here.
> > >
> > > Will do.
> > >
> > > /* Do not enable XFmode
Hi!
C23 added in N2956 ( https://open-std.org/JTC1/SC22/WG14/www/docs/n2956.htm )
two new attributes, which are described as similar to GCC const and pure
attributes, but they aren't really same and it seems that even the paper
is missing some of the differences.
The paper says unsequenced is the
> Is that from some kind of rigorous measurement under perf? As you
> surely know, 0.6% wall-clock time can be from boost clock variation
> or just run-to-run noise on x86.
I compared it using hyperfine which does rigorous measurements yes.
It was well above the run-to-run variability.
I had some
On Tue 2024-07-30 14:34:54, Richard Biener wrote:
> On Tue, 30 Jul 2024, Filip Kastl wrote:
>
> > > > > Ah, I see you fix those up. Then 2.) is left - the final block. Iff
> > > > > the final block needs adjustment you know there was a path from
> > > > > the default case to it which means one o
On Tue, Jul 30, 2024 at 08:41:59AM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> AVX2 is widely available on x86 and it allows to do the scanner line
> check with 32 bytes at a time. The code is similar to the SSE2 code
> path, just using AVX and 32 bytes at a time instead of SSE2 16 bytes.
>
From: Andi Kleen
... that uses -march=native -mtune=native to build a compiler optimized
for the host.
config/ChangeLog:
* bootstrap-native.mk: New file.
gcc/ChangeLog:
* doc/install.texi: Document bootstrap-native.
---
config/bootstrap-native.mk | 1 +
gcc/doc/install.texi
Hi,
On Tue, 30 Jul 2024, Andi Kleen wrote:
> AVX2 is widely available on x86 and it allows to do the scanner line
> check with 32 bytes at a time. The code is similar to the SSE2 code
> path, just using AVX and 32 bytes at a time instead of SSE2 16 bytes.
>
> Also adjust the code to allow inlini
On Mon, Jul 29, 2024 at 12:41 PM Björn Schäpers wrote:
>
> > Instead of deleting those, move them inside the parentheses:
> >
> > typedef VOID (CALLBACK *LDR_DLL_NOTIFICATION)(ULONG,
> > struct dll_notification_data*,
> >
As documented in PR116131, we might end up with the following
INSN for rv32i_xtheadmemidx after th_memidx_I_c is applied:
(insn 18 14 0 2 (set (mem:SI (plus:SI (reg/f:SI 141)
(ashift:SI (subreg:SI (reg:DI 134 [ a.0_1 ]) 0)
(const_int 2 [0x2]))) [0 S4 A32])
Nothing seems to change here in reality at least on x86_64-pc-linux-gnu,
but important to fix nonetheless in case people copy it.
PR rtl-optimization/48633
PR tree-optimization/83072
PR tree-optimization/83073
PR tree-optimization/96542
PR tree-optimization/
* gcc.target/aarch64/simd/vmmla.c: Fix whitespace in dg directive.
---
Committed as obvious.
gcc/testsuite/gcc.target/aarch64/simd/vmmla.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/simd/vmmla.c
b/gcc/testsuite/gcc.target/aarch64/
PR preprocessor/90581
* c-c++-common/cpp/fmax-include-depth.c: Fix whitespace in dg directive.
---
Committed as obvious.
gcc/testsuite/c-c++-common/cpp/fmax-include-depth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/c-c++-common/cpp/fmax-incl
Andrew Pinski writes:
>
> Using the builtin here seems wrong. Why not use the intrinsic
> _mm256_movemask_epi8 ?
I followed the rest of the vectorized code paths. The original reason was that
there was some incompatibility of the intrinsic header with the source
build. I don't know if it's still
On Tue, Jul 30, 2024 at 8:43 AM Andi Kleen wrote:
>
> From: Andi Kleen
>
> AVX2 is widely available on x86 and it allows to do the scanner line
> check with 32 bytes at a time. The code is similar to the SSE2 code
> path, just using AVX and 32 bytes at a time instead of SSE2 16 bytes.
>
> Also ad
From: Andi Kleen
Host systems with only MMX and no SSE2 should be really rare now.
Let's remove the MMX code path to keep the number of custom
implementations the same.
The SSE2 code path is also somewhat dubious now (nearly everything
should have SSE4 4.2 which is >15 years old now), but the SS
From: Andi Kleen
AVX2 is widely available on x86 and it allows to do the scanner line
check with 32 bytes at a time. The code is similar to the SSE2 code
path, just using AVX and 32 bytes at a time instead of SSE2 16 bytes.
Also adjust the code to allow inlining when the compiler
is built for an
Committed w/changelog fixup/sign-off and sent final version to the lists
here:
https://inbox.sourceware.org/gcc-patches/20240730152448.4089002-1-patr...@rivosinc.com/T/#u
Approved during risc-v patchworks meeting by Jeff Law.
Patrick
On 7/29/24 15:13, Patrick O'Neill wrote:
From: Gianluca Gui
From: Gianluca Guida
This patch adds support for amocas.{b|h|w|d}. Support for amocas.q
(64/128 bit cas for rv32/64) will be added in a future patch.
Extension: https://github.com/riscv/riscv-zacas
Ratification: https://jira.riscv.org/browse/RVS-680
gcc/ChangeLog:
* common/config/riscv
When this pattern was converted from being only dealing with 0/-1, we missed
that if `e == f` is true
then the optimization is wrong and needs an extra check for that.
This changes the patterns to be:
/* (a ? x : y) != (b ? x : y) --> (a^b & (x != y)) ? TRUE : FALSE */
/* (a ? x : y) == (b ? x :
The problem here is that in generic types of comparisons don't need
to be boolean types (or vector boolean types). And fixes that by making
sure the types of the conditions match before doing the optimization.
Bootstrapped and tested on x86_64-linux-gnu with no regressions.
PR middle-end/
Peter, Kewen:
Per Peter's request, I did the following testing on ltcd97-lp7 which is
a Power 10 running in BE mode.
On 7/29/24 8:47 AM, Peter Bergner wrote:
Maybe the following will work?
+/* { dg-do run { target power10_hw } } */
+/* { dg-do link { target { ! power10_hw } } } */
+/* { d
Committed with spaces -> tabs ChangeLog fix.
Patrick
On 7/29/24 20:27, Kito Cheng wrote:
LGTM, thanks :)
On Tue, Jul 30, 2024 at 10:53 AM Patrick O'Neill wrote:
This patch removes the zabha configure check since it's not a breaking change
and updates the existing zaamo/zalrsc comment.
gcc/C
I've pushed this for https://github.com/msys2/MSYS2-packages/issues/1937
but I'm taking a slightly different approach to Björn's original patch.
Instead of adding __detail::equivalent_win32 I'm adding fs::equiv_files
to do the check for both POSIX and Windows. The logic in do_copy_file
should be
> > IMO, what ought to happen here is that the RA should spill
> > the inner register to memory and load the V4SI back from there.
> > (Or vice versa, for an lvalue.) Obviously that's not very efficient,
> > and so a patch like the above might be useful as an optimisation.[*]
> > But it shouldn't
The old name was misleading.
While at it, also rename some temporary variables that are used with
this function, for consistency.
Link:
https://inbox.sourceware.org/gcc-patches/9fffd80-dca-2c7e-14b-6c9b509a7...@redhat.com/T/#m2f661c67c8f7b2c405c8c7fc3152dd85dc729120
Cc: Gabriel Ravier
Cc: Marti
Hi Richard, Jakub,
I've adjusted the ChangeLog; hopefully it'll be good now.
On Tue, Jul 30, 2024 at 12:22:01PM +0200, Richard Biener wrote:
> The changes look good to me, please leave the frontend maintainers
> time to chime in.
Sure; as much as they need. My latest patch
(-Wunterminated-strin
On 29/07/2024 08:30, Kyrylo Tkachov wrote:
> Hi Claudio,
>
>> On 26 Jul 2024, at 18:32, Claudio Bantaloukas
>> wrote:
>>
>> External email: Use caution opening links or attachments
>>
>>
>> This introduces the relevant flags to enable access to the fpmr register and
>> fp8 intrinsics, which w
This LWG issue is about to become Tentatively Ready.
Tested x86_64-linux.
-- >8 --
This uses remove_cv_t for the default template argument used for
deducing a type for a braced-init-list used with std::optional and
std::expected.
libstdc++-v3/ChangeLog:
* include/std/expected (expected
On Tue, Jul 30, 2024 at 03:00:49PM +0200, Richard Biener wrote:
> > What mangling fld performs depends on the contents of the FP control
> > word which is awkward.
For float/double loads (FLDS and FLDL) we know format conversion changes
SNaNs to QNaNs, but it's a widening conversion, so e.g. ro
On Tue, 30 Jul 2024 at 14:08, Jonathan Wakely wrote:
>
> On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
> wrote:
> >
> > Hello!
> >
> > The attached patch implements adds support for P2591R5 in libstdc++
> > (concatenation of strings and string_views, approved in Tokyo for C++26).
>
> Thanks for
On 29/07/2024 13:13, Richard Sandiford wrote:
> Claudio Bantaloukas writes:
>> Unlike most system registers, fpmr can be heavily written to in code that
>> exercises the fp8 functionality. That is because every fp8 instrinsic call
>> can potentially change the value of fpmr.
>> Rather than just
> On Jul 30, 2024, at 6:17 AM, Richard Biener wrote:
>
> The following adds a target hook to specify whether regs of MODE can be
> used to transfer bits. The hook is supposed to be used for value-numbering
> to decide whether a value loaded in such mode can be punned to another
> mode instead
On 7/30/24 7:01 AM, Lulu Cheng wrote:
在 2024/7/26 下午8:43, Xi Ruoyao 写道:
We already had "si3_extend" insns and we hoped the fwprop or combine
passes can use them to remove unnecessary sign extensions. But this
does not always work: for cases like x << 1 | y, the compiler
tends to do
(s
The following adds support for vector conditionals in C. The support
was nearly there already but c_objc_common_truthvalue_conversion
rejecting vector types. Instead of letting them pass there unchanged
I chose to instead skip it when parsing conditionals instead as a
variant with less possible f
On Tue, 30 Jul 2024 at 08:31, Giuseppe D'Angelo
wrote:
>
> Hello!
>
> The attached patch implements adds support for P2591R5 in libstdc++
> (concatenation of strings and string_views, approved in Tokyo for C++26).
Thanks for this patch as well. This was on my TODO list so I'll be
happy to not hav
On Mon, 29 Jul 2024 at 21:58, Giuseppe D'Angelo wrote:
>
> Hi,
>
> And this is the corresponding change libstdc++.
Thanks for the patch. Do you have a copyright assignment for GCC in
place, or are you covered by a corporate assignment for KDAB?
If not, please complete that process, or contribute
On Tue, Jul 30, 2024 at 03:00:49PM +0200, Richard Biener wrote:
> As Jakub said the padding is already dealt with in the caller
> though I only added that there for convenience since padding is
> problematic in general.
>
> If you think XFmode is safe to transfer 10 bytes we could enable it,
> I g
在 2024/7/26 下午8:43, Xi Ruoyao 写道:
We already had "si3_extend" insns and we hoped the fwprop or combine
passes can use them to remove unnecessary sign extensions. But this
does not always work: for cases like x << 1 | y, the compiler
tends to do
(sign_extend:DI
(ior:SI (ashift:SI (
On Tue, 30 Jul 2024, Alexander Monakov wrote:
>
> On Tue, 30 Jul 2024, Richard Biener wrote:
>
> > > Oh, and please add a small comment why we don't use XFmode here.
> >
> > Will do.
> >
> > /* Do not enable XFmode, there is padding in it and it suffers
> >from normalizatio
On Tue, 30 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 30, 2024 at 03:43:25PM +0300, Alexander Monakov wrote:
> >
> > On Tue, 30 Jul 2024, Richard Biener wrote:
> >
> > > > Oh, and please add a small comment why we don't use XFmode here.
> > >
> > > Will do.
> > >
> > > /* Do not en
On Tue, Jul 30, 2024 at 03:43:25PM +0300, Alexander Monakov wrote:
>
> On Tue, 30 Jul 2024, Richard Biener wrote:
>
> > > Oh, and please add a small comment why we don't use XFmode here.
> >
> > Will do.
> >
> > /* Do not enable XFmode, there is padding in it and it suffers
> >
On Tue, 30 Jul 2024, Richard Biener wrote:
> > Oh, and please add a small comment why we don't use XFmode here.
>
> Will do.
>
> /* Do not enable XFmode, there is padding in it and it suffers
>from normalization upon load like SFmode and DFmode when
>not using S
On Tue, 30 Jul 2024, Jakub Jelinek wrote:
> On Tue, Jul 30, 2024 at 02:26:05PM +0200, Richard Biener wrote:
> > > > (Which implies that we should introduce TARGET_I387_MATH to parallel
> > > > TARGET_SSE_MATH some day...)
> > > >
> > > > > + default:
> > > > > + return false;
> > > >
>
1 - 100 of 142 matches
Mail list logo
