binutils-apple/sim/testsuite/mcore/ at master · theoparis.com/binutils-apple · Tangled

theoparis.com / binutils-apple

0

WIP MachO binutils port assisted by AI I may consider upstreaming this in the future.

0

binutils-apple / sim / testsuite / mcore /

at master 10 files

Jeff Law Yet another fix for mcore-sim (rotli) 2y ago

Yet another fix for mcore-sim (rotli) This came up testing the CRC optimization work from Mariam@RAU. Basically to optimize some CRC loops into table lookups or carryless multiplies, we may need to do a bit reflection, which on the mcore processor is done using a rotate instruction. Unfortunately the simulator implementation of rotates has the exact same problem as we saw with right shifts. The input value may have been sign extended from 32 to 64 bits. When we rotate the extended value, we get those sign extension bits and thus the wrong result. The fix is the same. Rather than using a "long", use a uint32_t for the type of the temporary. This fixes a handful of tests in the GCC testsuite:

2 years ago

sim: testsuite: cleanup the istarget * logic Now that the multitarget testing has settled, clean up the cases where istarget * is used. This ends up being mostly style unindenting.

5 years ago

sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.

5 years ago

Fix right shifts in mcore simulator on 64 bit hosts. If the value to be shifted has the sign bit set, the sign bit would get copied into bits 32..63 of the temporary. Those would then be right shifted into the final value giving an incorrect final result. This was observed with upcoming GCC improvements which eliminate unnecessary extensions.

2 years ago

Fix right shifts in mcore simulator on 64 bit hosts. If the value to be shifted has the sign bit set, the sign bit would get copied into bits 32..63 of the temporary. Those would then be right shifted into the final value giving an incorrect final result. This was observed with upcoming GCC improvements which eliminate unnecessary extensions.

2 years ago

sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.

5 years ago

Yet another fix for mcore-sim (rotli) This came up testing the CRC optimization work from Mariam@RAU. Basically to optimize some CRC loops into table lookups or carryless multiplies, we may need to do a bit reflection, which on the mcore processor is done using a rotate instruction. Unfortunately the simulator implementation of rotates has the exact same problem as we saw with right shifts. The input value may have been sign extended from 32 to 64 bits. When we rotate the extended value, we get those sign extension bits and thus the wrong result. The fix is the same. Rather than using a "long", use a uint32_t for the type of the temporary. This fixes a handful of tests in the GCC testsuite:

2 years ago

[RFA] Fix for mcore simulator I was looking for cases where a GCC patch under evaluation would cause test results to change. Quite surprisingly the mcore-elf port showed test differences. After a fair amount of digging my conclusion was the sequences before/after the patch should have been semantically the same. Of course if the code is supposed to behave the same, then that points to problems elsewhere (assembler, linker, simulator). Sure enough the mcore simulator was mis-handling the sign extension instructions. The simulator implementation of sextb is via paired shift-by-24 operations. Similarly the simulator implements sexth via paired shift-by-16 operations. The temporary holding the value was declared as a "long" thus this approach worked fine for hosts with a 32 bit wide long and failed miserably for hosts with a 64 bit wide long. This patch makes the shift count automatically adjust based on the size of the temporary. It includes a simple test for sextb and sexth. I have _not_ done a full audit of the mcore simulator for more 32->64 bit issues. This also fixes 443 execution tests in the GCC testsuite

2 years ago

[RFA] Fix for mcore simulator I was looking for cases where a GCC patch under evaluation would cause test results to change. Quite surprisingly the mcore-elf port showed test differences. After a fair amount of digging my conclusion was the sequences before/after the patch should have been semantically the same. Of course if the code is supposed to behave the same, then that points to problems elsewhere (assembler, linker, simulator). Sure enough the mcore simulator was mis-handling the sign extension instructions. The simulator implementation of sextb is via paired shift-by-24 operations. Similarly the simulator implements sexth via paired shift-by-16 operations. The temporary holding the value was declared as a "long" thus this approach worked fine for hosts with a 32 bit wide long and failed miserably for hosts with a 64 bit wide long. This patch makes the shift count automatically adjust based on the size of the temporary. It includes a simple test for sextb and sexth. I have _not_ done a full audit of the mcore simulator for more 32->64 bit issues. This also fixes 443 execution tests in the GCC testsuite

2 years ago

sim: testsuite: flatten tree Now that all port tests live under testsuite/sim/*/, and none live in testsuite/ directly, flatten the structure by moving all of the dirs under testsuite/sim/ to testsuite/ directly. We need to stop passing --tool to dejagnu so that it searches all dirs and not just ones that start with "sim". Since we have no other dirs in this tree, and no plans to add any, should be fine.

5 years ago