[Bug target/89411] RISC-V backend will generate wrong instruction for longlong type like lw a3,-2048(a5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89411 Tao Wang changed: What|Removed |Added CC||wangtao42 at huawei dot com --- Comment #2 from Tao Wang --- When using gdb debugging this, I forced the riscv_valid_lo_sum_p return false, and it do solve this problem. But in function riscv_valid_lo_sum_p a lot of information to identify the wrong scene has been lost. I think it may work that using a global var which is defined in expand_XXX, but it seems like not good. So is there another way to solve this? Or how can identify the wrong scene? Thanks
[Bug rtl-optimization/90049] New: Wrong expanding for a unsigned short ssa_name in embedded assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90049
Bug ID: 90049
Summary: Wrong expanding for a unsigned short ssa_name in
embedded assembly code.
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wangtao42 at huawei dot com
Target Milestone: ---
Created attachment 46143
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46143&action=edit
testcase
A unsigned short ssa_name in embedded assembly code will be expanded to
subreg:HI, and without the bit extracting action. It will result in a wrong
assembly code.
The attachment is the testcase, and the command is as follows:
mips-sde-elf-gcc -O2 -S t2.c
And the result assembly code is:
func:
.frame $sp,0,$31 # vars= 0, regs= 0/0, args= 0, gp= 0
.mask 0x,0
.fmask 0x,0
lw $3,0($4)
lw $2,%gp_rel(g_b)($28)
srl $4,$3,24
sw $3,%gp_rel(g_a)($28)
ext $6,$2,0,17
sltu$7,$4,1
#APP
# 27 "t2.c" 1
addiu $5, $6, 0
movn $5, $3, $7
# 0 "" 2
#NO_APP
ins $2,$5,0,17
.setnoreorder
.setnomacro
jr $31
sw $2,%gp_rel(g_b)($28)
It is wrong that the $3 is loaded a word from 0($4), and the $3 should be the
low 16bit of 0($4). I guess something wrong with expand_gimple_basic_block, and
this ignore should not be used in embedded assembly code:
5822 def_p = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_DEF);
5823
5824 if (def_p != NULL)
5825 {
5826 /* Ignore this stmt if it is in the list of
5827 replaceable expressions. */
5828 if (SA.values
5829 && bitmap_bit_p (SA.values,
5830SSA_NAME_VERSION (DEF_FROM_PTR
(def_p
5831 continue;
5832 }
5833 last = expand_gimple_stmt (stmt);
Please help to check this.
Thanks
[Bug rtl-optimization/90049] Wrong expanding for a unsigned short ssa_name in embedded assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90049 --- Comment #1 from Tao Wang --- I also checked this in arm64 and arm32 backend, and it can be reproduced also.
[Bug rtl-optimization/90049] Wrong expanding for a unsigned short ssa_name in embedded assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90049 --- Comment #3 from Tao Wang --- (In reply to Eric Botcazou from comment #2) > The 6.x series of compilers is no longer supported. Please try with a newer > version, preferably the latest release (GCC 8.3). Hi Eric, I tried with gcc-7.3.0, gcc-8.3.0, and even the lastest version on trunk branch, but this problem is also existed. Thanks, Tao Wangtao
[Bug rtl-optimization/90049] Wrong expanding for a unsigned short ssa_name in embedded assembly code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90049
--- Comment #5 from Tao Wang ---
(In reply to Eric Botcazou from comment #4)
> This is not a bug:
>
> __asm__ __volatile__ ("addiu %0, %1, 0\t\n" "movn %0, %2, %3" :
> "=&r"(g_b.s_b.c):"r"(g_b.s_b.c),"r"(g_a.s_a.c),"r"((0 == g_a.s_a.a)));
>
> The movn instruction uses 32-bit quantities but g_a.s_a.c is only 16-bit and
> there is no implicit cast for asm operands. You need to write it like this:
>
> __asm__ __volatile__ ("addiu %0, %1, 0\t\n" "movn %0, %2, %3" :
> "=&r"(g_b.s_b.c):"r"((int)g_b.s_b.c),"r"((int)g_a.s_a.c),"r"((0 ==
> g_a.s_a.a)));
But if g_a.s_a.c is 17 bits width, then there is a bit extract action like
this: ubfxx3, x3, #0, #17.
So why does this can work and the 16 bit width can not?
