https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
--- Comment #3 from YunQiang Su ---
I cannot reproduce this problem (with Debian Sid)
1) apt install g++-riscv-linux-gnu linux-libc-dev-riscv64-cross
2) ../configure --prefix=/usr --disable-multilib --with-arch=rv64gc
--with-abi=lp64d --target=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
--- Comment #2 from YunQiang Su ---
Can you give out the output of
`./build-gcc-linux-stage2/gcc/xgcc -B./build-gcc-linux-stage2/gcc/ -v`
and
`tree
/scratch/ewlu/ci/triage/baseline/hash-ead5f587dad3206e45db7ac31f5c34c1530ae529/sysroot/`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116686
--- Comment #1 from YunQiang Su ---
It fixed the multlib path problem.
I guess that the problem is due to that ld-linux-riscv64-lp64d.so.1 found wrong
libraries.
Can you try to run pr114734.exe manually with LD_DEBUG=all option?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116475
Bug ID: 116475
Summary: autovect: may be optimized for min/max
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115840
YunQiang Su changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 115840, which changed state.
Bug 115840 Summary: RISC-V with V:‘({anonymous})’ may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115840
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115840
--- Comment #3 from YunQiang Su ---
Created attachment 58621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58621&action=edit
preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115840
--- Comment #1 from YunQiang Su ---
> If I use `-march=rv64imafdcv`, the problem won't happen.
Typo: `-march=rv64imafdc`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115840
Bug ID: 115840
Summary: RISC-V with V:‘({anonymous})’ may be used
uninitialized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115678
Bug ID: 115678
Summary: MIPS: Condition trap can optimize
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115453
YunQiang Su changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #18 from YunQiang Su ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654956.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #17 from YunQiang Su ---
I send the patch here.
So we may need some more test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500
--- Comment #5 from YunQiang Su ---
(In reply to Jeffrey A. Law from comment #4)
> On the gcc-13, gcc-14 and the trunk I get this with -O2 on rv64gc:
>
> sllia5,a0,44
> blt a5,zero,.L3
>
>
> So ISTM that we must be doi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #14 from YunQiang Su ---
And it seems that the performance of SLL is related with the operand.
Just iterate from 0 to 1e9:
```
0b00 :
b00: 000223c0sll a0,v0,0xf <-- the code is something
wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #13 from YunQiang Su ---
I try to insert
li $3, 500
li $5, 500
between SLL/BGEZ and LUI+AND/BNE.
The later is still some faster on Loongson 3A4000.
I notice something like this in 74K's software manual:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500
--- Comment #3 from YunQiang Su ---
(In reply to Andrew Pinski from comment #2)
> The big question is non zbs riscv arch matter any more?
I have no idea. This is the Debian's porterbox, so I guess it meets the
requirement of Debian's RV64 port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500
--- Comment #1 from YunQiang Su ---
Talks about MIPS here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115500
Bug ID: 115500
Summary: RISC-V: Performance regression on 1bit test
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
YunQiang Su changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #10 from YunQiang Su ---
I have some performance test.
sll+bgez is some slower than lui+and+beqz.
On Loongson 3A4000, it is about 10%.
So this "optimization" makes sense only for -Os.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115473
Bug ID: 115473
Summary: MIPS: -Os rtx_cost compare not correct
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #9 from YunQiang Su ---
I see about condmove: it is broken since gcc14.
int
f32(int a)
{
int p = (a & (1<<16));
if (p)
return 100;
else
return 1000;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416
--- Comment #7 from YunQiang Su ---
Maybe this patch is better
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -560,11 +560,7 @@ LINKER_PLUGIN_API_H = $(srcdir)/../include/plugin-api.h
# Default native SYSTEM_HEADER_DIR, to be overridden by tar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416
--- Comment #6 from YunQiang Su ---
(In reply to Marcus Calhoun-Lopez from comment #5)
> (In reply to YunQiang Su from comment #3)
> > Since it doesn't exist, why use --includedir with it?
>
> /opt/local/include/gcc is where the header files wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416
--- Comment #3 from YunQiang Su ---
Since it doesn't exist, why use --includedir with it?
Anyway, so, maybe we should detect the existence of this dir.
Can you have a try of this patch?
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -560,10 +56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115416
--- Comment #2 from YunQiang Su ---
Can you give me the configure command, so that I can have a test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115393
Bug ID: 115393
Summary: MIPS: implemented _BitInt of C23
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #7 from YunQiang Su ---
Ohh, I need add "&&" before "!reload_completed".
It seems work with -Os.
can you give me you test code?
I cannot figure out a non-workable condmove C code for it.
With the constant less than 0x, AN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #5 from YunQiang Su ---
I copy the RTL pattern from RISC-V, and it seems work
```
--- a/gcc/config/mips/mips.md
+++ b/gcc/config/mips/mips.md
@@ -6253,6 +6253,40 @@ (define_insn "*branch_bit_inverted"
}
[(set_attr "type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #4 from YunQiang Su ---
Ohh, RISC-V has solved this problem in recent release.
So we can just do similar work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #2 from YunQiang Su ---
(In reply to YunQiang Su from comment #1)
> RISC-V has this problem, too.
> Maybe we can try to combine it in `combine` pass, while it may be not easy.
> It may break some code like:
>
> ```
> int f1();
> int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #1 from YunQiang Su ---
RISC-V has this problem, too.
Maybe we can try to combine it in `combine` pass, while it may be not easy.
It may break some code like:
```
int f1();
int f2();
int f(int a) {
int p = (a & 0x8);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115286
Bug ID: 115286
Summary: MIPS: mips16_rdhwr_one_only_stub::output_body clobber
$3
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106136
YunQiang Su changed:
What|Removed |Added
CC||syq at gcc dot gnu.org
Resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100760
YunQiang Su changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245
--- Comment #4 from YunQiang Su ---
It has been fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89245
YunQiang Su changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82051
YunQiang Su changed:
What|Removed |Added
Resolution|--- |INVALID
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
YunQiang Su changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #14 from YunQiang Su ---
Ohh, sorry for my misunderstanding. Your patch is correct.
The real problem is that, $3 is used by `mips_output_function_prologue`,
which is the final for output asm source code, and thus the IRA pass
cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #12 from YunQiang Su ---
You are right: the decision to use $6 is too late.
So let's force to use it in expand pass.
```
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index b63d40a357b..84ff29cd62b 100644
--- a/gcc/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #11 from YunQiang Su ---
(In reply to YunQiang Su from comment #8)
> Ohh, In fact we should use $28 if TARGET_USE_GOT.
>
> Can you help to test this patch?
>
> ```
> diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
> i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #9 from YunQiang Su ---
(In reply to Matthias Schiffer from comment #7)
> (In reply to YunQiang Su from comment #6)
> > The attached patch cannot work now.
> >
> > It is not correct, and it happened work due to good luck that the sam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #8 from YunQiang Su ---
Ohh, In fact we should use $28 if TARGET_USE_GOT.
Can you help to test this patch?
```
diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index b63d40a357b..fe8641d3916 100644
--- a/gcc/config/mip
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
--- Comment #6 from YunQiang Su ---
The attached patch cannot work now.
It is not correct, and it happened work due to good luck that the same register
was allocated for these 2 instructions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84790
YunQiang Su changed:
What|Removed |Added
Last reconfirmed||2024-05-22
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113932
Bug 113932 depends on bug 113955, which changed state.
Bug 113955 Summary: Finish LRA transition for mips by removing -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955
YunQiang Su changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114976
Bug ID: 114976
Summary: MIPS64: get double high part can use mfhc1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180
--- Comment #3 from YunQiang Su ---
The argument `to` of `expand_assignment` differs between `strict-align` and
`no-strict-align`.
`debug_tree` states that the `strict-align` one has a `MEMREF` RTL, while
`no-strict-align` has a `reg` one.
An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
--- Comment #6 from YunQiang Su ---
With some test on some CPUs, in fact, the lacking of `sll` won't make troubles
to us.
It seems that most of MIPS64 CPUs can process it well as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
YunQiang Su changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
--- Comment #3 from YunQiang Su ---
36088299955f95ab58a5758cba2f29b84c8fbfbc is the first bad commit
commit 36088299955f95ab58a5758cba2f29b84c8fbfbc
Author: Richard Biener
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114344
Bug ID: 114344
Summary: [arm/mips] __alignof__ report a member packed struct
as 1, while normal load/store instruction is used
Product: gcc
Version: unknown
Status: UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111555
YunQiang Su changed:
What|Removed |Added
CC||syq at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955
--- Comment #3 from YunQiang Su ---
-mlra has been set to default since it was added (2014).
So, It is ok for us to remove it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113955
--- Comment #2 from YunQiang Su ---
Maybe we can set it as the release target of GCC 15.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655
YunQiang Su changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113655
--- Comment #1 from YunQiang Su ---
Thank for your report. It's due to a typo
I will fix it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
YunQiang Su changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
--- Comment #1 from YunQiang Su ---
In file included from
../../../../../libstdc++-v3/src/c++17/floating_from_chars.cc:86:
../../../../../libstdc++-v3/src/c++17/fast_float/fast_float.h: In function
‘std::from_chars_result {anonym
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113354
Bug ID: 113354
Summary: Regression/14: unable to find a register to spill on
mips
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
YunQiang Su changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113227
YunQiang Su changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113227
--- Comment #1 from YunQiang Su ---
Sorry for noise. This proposal is wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113227
Bug ID: 113227
Summary: Maybe optimization (a>0) && (b>0) with or&<0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113185
Bug ID: 113185
Summary: bad performance on big-endian&64bit port for struct 16
16
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113180
Bug ID: 113180
Summary: MIPS: bitops on an long long struct uses ins instead
dins
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113179
Bug ID: 113179
Summary: MIPS
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #23 from YunQiang Su ---
I guess, we should drop TRULY_NOOP_TRUNCATION_MODES_P and
TARGET_MODE_REP_EXTENDED for MIPS. In fact, it will only effect MIPS64 SI->DI.
Then it may reduce the maintain workload for MIPS64.
Let's have a try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #22 from YunQiang Su ---
Any way, we should split the assert to another patch.
I will try to find all the wrongly used TRULY_NOOP_TRUNCATION_MODES_P.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #21 from YunQiang Su ---
Sorry, Roger. Your patch is correct.
I misunderstood it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #20 from YunQiang Su ---
This patch has 2 problems:
1. We may need some more steps to add
gcc_assert (outprec < inprec)
Now, I met some ICE with it.
2. It doesn't solve the this problem:
In combine.cc, jump_insn eats trunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
YunQiang Su changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #6 from YunQiang Su ---
ohh, it should be concat(" ", NULL);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112759
--- Comment #5 from YunQiang Su ---
It's my fault.
I misunderstanding `reconcat`:
if `optr` is NULL, it cannot work as the `s1` at the sametime.
If so, the return string will be empty.
So, let's define and initial ret like this:
char *ret = c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #16 from YunQiang Su ---
(In reply to Roger Sayle from comment #15)
> Is MIPS64 actually a TRULY_NOOP_TRUNCATION_TARGET? If SImode is implicitly
> assumed to be (sign?) extended, then an arbitrary DImode value/register
> can't be us
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #14 from YunQiang Su ---
New patch:
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index fbd4ce2d42f..66d45da67df 100644
--- a/gcc/expmed.cc
+++ b/gcc/expmed.cc
@@ -850,6 +850,7 @@ store_bit_field_1 (rtx str_rtx, poly_uint64 bitsize,
po
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #13 from YunQiang Su ---
This tiny patch works will this small test case by replace with dins to ins.
I have no idea whether it will have any side effects.
Any idea?
diff --git a/gcc/expmed.cc b/gcc/expmed.cc
index fbd4ce2d42f..37
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #8 from YunQiang Su ---
(In reply to Andrew Pinski from comment #7)
> The initial RTL has a signed extend in there:
>
>
> (insn 20 19 23 2 (set (reg/v:DI 200 [ val+-4 ])
> (sign_extend:DI (subreg:SI (reg/v:DI 200 [ val+-4 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
YunQiang Su changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105614
YunQiang Su changed:
What|Removed |Added
CC||syq at gcc dot gnu.org
--- Comment #21 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #6 from YunQiang Su ---
In RTL (xx.c.256r.expand), there is
(insn 10 9 11 2 (set (zero_extract:DI (reg/v:DI 200 [ val ])
(const_int 8 [0x8])
(const_int 0 [0]))
(subreg:DI (reg:QI 202) 0)) "xx.c":4:29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #5 from YunQiang Su ---
Another possible fix is to emit a SLL for extendsidi2, but
I am worrying about it may break something else.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #3 from YunQiang Su ---
Ohhh, I think that the real problem is that:
why DINS is used instead of INS when work with an INT?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
YunQiang Su changed:
What|Removed |Added
CC||syq at gcc dot gnu.org
--- Comment #2 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109435
YunQiang Su changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
88 matches
Mail list logo
