store instructions may fail when a CSR is written about scr1 HOT 6 CLOSED

Hi @gambaman,

It seems a compiler issue, the application becomes overoptimized. I'm looking into details to find the root cause and stable fix.

BR,
Alexander

from scr1.

Hi @gambaman,

It seems a compiler issue, the application becomes overoptimized. I'm looking into details to find the root cause and stable fix.

BR, Alexander

Hello, Alexander. I thought it could be a compiler issue, but then I looked at the assembler code in the dump file and the store half instruction is unconditionally executed when little_endian_SH is called. Look bellow:

00481106 <little_endian_SH>:
  481106:	95b2                	add	a1,a1,a2
  481108:	300027f3          	csrr	a5,mstatus
  48110c:	30079073          	csrw	mstatus,a5
  481110:	0542                	sll	a0,a0,0x10
  481112:	01055293          	srl	t0,a0,0x10
  481116:	00559023          	sh	t0,0(a1)
  48111a:	4681                	li	a3,0
  48111c:	4601                	li	a2,0
  48111e:	4581                	li	a1,0
  481120:	aa818513          	add	a0,gp,-1368 # 4820c8 <__clz_tab+0x150>
  481124:	b5f1                	j	480ff0 <sc_printf>

from scr1.

You have strict aliasing violation between:

uint32_t result
volatile uint16_t* efective_address

You can compile with -fno-strict-aliasing all will work.

Reduced x86 example: https://godbolt.org/z/Eqao1K9T1

from scr1.

You have strict aliasing violation between:

uint32_t result
volatile uint16_t* efective_address

You can compile with -fno-strict-aliasing all will work.

Reduced x86 example: https://godbolt.org/z/Eqao1K9T1

Hello, Kv-sc. The example code I used is helpless. I could just remove the CSR access or the sc_printf call and it will work. That is not the problem. The problem is that (apparently) scr1 is not working properly.

from scr1.

You have strict aliasing violation between:

uint32_t result
volatile uint16_t* efective_address

You can compile with -fno-strict-aliasing all will work.

Reduced x86 example: https://godbolt.org/z/Eqao1K9T1

Hello, Kv-sc. You are right. Because of the strict aliasing violation the compiler use the constant 0x88888888 as actual parameter in when calling test_instruction:

481144: 21060613 add a2,a2,528 # 88883210 <__C_STACK_TOP__+0x883f3210> 481148: 88858593 add a1,a1,-1912 # 88888888 <__C_STACK_TOP__+0x883f8888> 48114c: b0418513 add a0,gp,-1276 # 482124 <__clz_tab+0x1ac> 481150: 35d9 jal 481016 <test_instruction>

Thank you very much

from scr1.

Hi @gambaman,

It seems a compiler issue, the application becomes overoptimized. I'm looking into details to find the root cause and stable fix.

BR, Alexander

As noted by you and by Kv-sc, it is a compiler issue.

from scr1.