Thanks Jeff for the confirmation and suggestions. It looks like not a corner
case for the option no-signed-zero.
Consider 2 sample function as below with build with option " -march=rv64gcv
-mabi=lp64d -O2 -fno-signed-zeros".
void
__attribute__ ((noinline))
test_float_zero_assign_0 (float *a)
{
I've been at this for a while, and I'm not sure what the proper way to
fix this is.
```
struct S;
struct B {
void f(this S&) {}
void g() {}
};
struct S : B {
using B::f;
using B::g;
void f() {}
void g(this S&) {}
};
int main()
{
S s{};
s.f();
s.g();
}
```
In short, the call t
That was faster than I expected, the problem is exactly just that we
aren't implementing [over.match.funcs.general.4] at all. The result of
compparms for the 2 functions is false which I believe to be wrong. I
believe we have a few choices here, but no matter what we go with it
will be a bit of an
When building multilib libraries, CC/CXX etc are set with an option
-B*/lib/, instead of -B/lib/.
This will make some trouble in some case, for example building
cross toolchain based on Debian's cross packages:
If we have libc6-dev-i386-amd64-cross packages installed on
a non-x86 machine. This
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113191
I've posted the report here, I ended up doing a bit more investigation,
so the contents might interest you. I'm really starting to think that
we want to do a more thorough re-engineering of how using declarations
are handled, instead of handling
I know we're deep into stage3 and about to transition to stage4. So if
the consensus is for this to wait, I'll understand
This it the V3 of the ext-dce patch based on Joern's work from last year.
Changes since V2:
Handle MINUS
Minor logic cleanup for SUBREGs in ext_dce_process_sets
I
Hi Thomas!
Am 30.12.23 um 12:08 schrieb Thomas Koenig:
Replying to myself...
I think this also desevers a mention in changes.html. Here is something
that I came up with. OK? Or does anybody have suggestions for a better
wording?
Or maybe this is better:
diff --git a/htdocs/gcc-14/change
This is Ok from my side.
But before commit this patch, I think we need this patch first:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/641533.html
I will be back to work so I will take a look at other patches today.
juzhe.zh...@rivai.ai
From: Jeff Law
Date: 2024-01-01 01:43
To: Jun
Co-Authored by: Songhe Zhu
Co-Authored by: Ciyan Pan
gcc/ChangeLog:
* config/riscv/iterators.md: Add rotate insn name.
* config/riscv/riscv.md: Add new insns name for crypto vector.
* config/riscv/vector-iterators.md: Add new iterators for crypto vector.
* config/
LGTM assume you have passed the regression.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2023-12-29 12:06
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v4] RISC-V: C
LGTM assume you have passed the regression.
juzhe.zh...@rivai.ai
From: Jun Sha (Joshua)
Date: 2023-12-29 12:10
To: gcc-patches
CC: jim.wilson.gcc; palmer; andrew; philipp.tomsich; jeffreyalaw;
christoph.muellner; juzhe.zhong; Jun Sha (Joshua); Jin Ma; Xianmiao Qu
Subject: [PATCH v4] RISC-V: C
Pushed to r14-6879 and modified this issue.
在 2023/12/19 下午8:37, Xi Ruoyao 写道:
On Tue, 2023-12-19 at 19:04 +0800, Lulu Cheng wrote:
+(define_insn "@add_tls_le_relax"
+ [(set (match_operand:P 0 "register_operand" "=r")
+ (unspec:P [(match_operand:P 1 "register_operand" "r")
+
Committed.
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc: Move STMT_VINFO_TYPE (...) to
local.
---
gcc/config/riscv/riscv-vector-costs.cc | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/gcc/config/riscv/riscv-vector-costs.cc
b/gcc/config/riscv/riscv-
gcc/ChangeLog:
* config/riscv/vector-crypto.md: Modify copyright year.
---
gcc/config/riscv/vector-crypto.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/config/riscv/vector-crypto.md
b/gcc/config/riscv/vector-crypto.md
index e40b1543954..9625014e45e 100755
---
For vsetvl issues, what we want to do here is to directly
remove "t" and "m".
If we add TARGET_XTHEADVECTOR logic in case "p" in
riscv_print_operand, how can we remove "t" and "m"? If I
use "break", assembly like "th.vsetvli zero,a5,e8,m1,t,m"
will be returned.
if (TARGET_THEADVECTOR)
...
else
Tested mmix-knuth-mmixware (where all torture-variants of
gcc.dg/torture/inline-mem-cpy-1.c now pass) and native
x86_64-pc-linux-gnu. Also stepped through the test for native,
w/wo. RUN_FRACTION defined to see that it worked as intended.
You may wonder what about the "sibling" tests inline-mem-cm
This patch fixes the following situation:
vl4re16.v v12,0(a5)
...
vl4re16.v v16,0(a3)
vs4r.v v12,0(a5)
...
vl4re16.v v4,0(a0)
vs4r.v v16,0(a3)
...
vsetvli a3,zero,e16,m4,ta,ma
...
vmv.v.x v8,t6
vmsgeu.vv v2,v16,v8
vsub.vv v16,v16,v8
vs4r.v v16,0(a5)
...
vs4r.v v4,0(a0)
v
But the riscv_print_operand() function returns void.
We cannot return instructions like riscv_output_move.
I think the briefest approach is to add some logic in
the vsetvl patterns.
"TARGET_VECTOR"
{ return TARGET_XTHEADVECTOR ? "vsetvli\t%0,%1,e%2,%m3" :
"vset%i1vli\t%0,%1,e%2,%m3,t%p4,m%p5";
On Fri, Dec 22, 2023 at 6:25 PM Roger Sayle wrote:
>
>
> This patch resolves the second part of PR target/112992, building upon
> Hongtao Liu's solution to the first part.
>
> The issue addressed by this patch is that when initializing vectors by
> broadcasting integer constants, the compiler has
In
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d1eacedc6d9ba9f5522f2c8d49ccfdf7939ad72d
I optimize COND_LEN_xxx pattern with dummy len and dummy mask with too simply
solution which
causes redundant vsetvli in the following case:
vsetvli a5,a2,e8,m1,ta,ma
vle32.v v8,0(a0)
Patch v5:Rebase.
Patch v4:Merge crypto vector function.def into vector.
Patch v3:Define a shape for vaesz and merge vector-crypto-types.def
into riscv-vector-builtins-types.def.
Patch v2:Optimize function_shape class for crypto_vector.
This patch add the intrinsic funtions of crypto vecto
Patch v5: Rebase.
Patch v4: Add some RV32 vx constraint testcase.
Patch v3: Refine crypto vector api-testing case s.
Patch v2: Update march info according to the change of riscv-common.c
This patch add crypto vector api-testing cases based on
https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob
+/* Static information about a set of crypto vector functions. */
+struct crypto_function_group_info
+{
+ struct function_group_info rvv_function_group_info;
+ /* Whether the function is available. */
+ unsigned int (*avail) (void);
+};
What is this used for ?
juzhe.zh...@rivai.ai
From: F
23 matches
Mail list logo
