I-SB-01 test war hazard (address register) about riscv-arch-test HOT 7 CLOSED

Yep, that's very wrong. A lot of these inline assertions are wrong -- the only correct way to run the tests is to compile the test suite without them, via make RISCV_TARGET=spike.

from riscv-arch-test.

I don't think a lot of assertions are wrong, infact for the rv32i testset this is the only one that doesn't work for my port.

from riscv-arch-test.

Well, some of the assertion macros are wrong even though they pass on most platforms, since they introduce side effects that change the outcome of the test. I-ADD-01.S is an example; line 84 asserts that a register should be 0 when it should be 1; however, the assertion passes anyway because the register ends up getting set to 0 by the macro itself. See below email from a few days ago to the compliance working group:

The macros are target dependent and are implemented in compliance_io.h, e.g. RVTEST_IO_ASSERT_GPR_EQ. Some registers are said to be reserved and are used by the tests.

False errors get reported by macros because the checked value is a side effect of the macro implementation. As an example rv32i/src/I-ADD-01.S line 84: the code asserts x5 is 0, but the signature checks it should be 1.

The macros are pretty useful because they basically run in many environments. The asserted value should check the real value, and not a side effect of the checking macro. If a macro is using reserved registers, then it should check it and not execute it if a conflict occurs. It is likely possible to use target specific macros that can use fixed memory locations to swap registers and thus avoid solve reserved register issues.

Last comment: by not implementing the macros, it is possible to skip it. If macros are choosen, it is however not possible to skip saving the signature to memory. It would probably save memory and accelerate tests if it was possible to disable signature saving when using self-checking macros.

from riscv-arch-test.

I believe this assertion is incorrect as it uses a fixed value in an address.
In fact it is not a good idea to assert on any register whose value is derived from a relocatable address (from the linker script)

Additionally use of the pre-defined reserved registers is also not compatible with the ASSERT.
This specific ASSERT needs to be removed, and we need to do a sweep of the tests to ensure reserved registers are not used in ASSERTs

from riscv-arch-test.

I just cloned the riscv repo, run the compliance suite and encountered these failures. So the good news is its repeatable. 😄 However, this issue has not been commented on for almost 10 months and is currently not assigned to anyone. How can we move this issue along?

from riscv-arch-test.

I just looked at the latest code, and it doesn't resemble the code above. The newest version has an explicit scratch register in the macro arguments, and doesn't check the contents of the scratch register. Could you ensure you ran this with the latest? E.g. the example above has : RVTEST_IO_ASSERT_GPR_EQ(x27, 0x89ABCDEF) while the latests tests look like RVTEST_IO_ASSERT_GPR_EQ(x2, x26, 0x7654321)

from riscv-arch-test.

This issue no longer exists as the macros have been updated in the test and there is no longer checks on the contents on the signature section

from riscv-arch-test.