which commit produces this?

i possibly missed overwriting some field in the cached object.

caching is pretty important here, since iirc it made the simulator like 40% faster or something crazy like that.

(In reply to Jacob Lifshay from comment #1)
> which commit produces this?

I'm guessing:
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_pospopcount.py;h=8c73ce7162d0f1b69a1ee5c3f2565c2c85ce481e;hb=b427a6cc523dc5a277d0e379848e4bad90568592#l39

I'll debug it later today, probably.

turns out it's ok - however i *really* do not want to see surprises
like that in future. i *have* to be able to keep track of what is
going on in ISACaller, *from memory* not from "what is in the code"
as it is simply far, far too complex.

 resolved as the actual problem turned out to be
 elwidth overrides on a LD/ST-update setting RA
 to 8-bit, which is a spec violation. dw=8 was
 supposed to only apply to RT.  tracking that down
 when being alarmed/surprised at diffs showing
 is_svp64_mode *true*...

 but yes can you please check. i initially thought
 about closing this but then realised it does actually
 need checking.

(In reply to Jacob Lifshay from comment #1)
> which commit produces this?

since you never replied to that, I tested on:

commit b427a6cc523dc5a277d0e379848e4bad90568592
Author: Luke Kenneth Casson Leighton <lkcl@lkcl.net>
Date:   Wed Nov 29 15:06:18 2023 +0000

    bug #672: shorter pospopcount but not fully working

I was unable to reproduce the bug after running the test over 250 times.

I modified setup_next_insn in caller.py (the only spot is_svp64_mode can be set to True) to add an allowlist of which CIA values are known to be SVP64 instructions:

--- a/src/openpower/decoder/isa/caller.py
+++ b/src/openpower/decoder/isa/caller.py
@@ -1777,6 +1777,9 @@ class ISACaller(ISACallerHelper, ISAFPHelpers, StepLoop):
         pfx = self.__decode_prefix(opcode)
         log("prefix test: opcode:", pfx.PO, bin(pfx.PO), pfx.id)
         self.is_svp64_mode = bool((pfx.PO == 0b000001) and (pfx.id == 0b11))
+        if self.is_svp64_mode:
+            assert self.pc.CIA.value in (0xC, 0x1C, 0x24, 0x2C, 0x34), \
+                "pc = 0x%x" % self.pc.CIA.value
         self.pc.update_nia(self.is_svp64_mode)
         # set SVP64 decode
         yield self.dec2.is_svp64_mode.eq(self.is_svp64_mode)

and then tested on 32 threads in an infinite loop in bash:
for i in {0..31}; do (while SILENCELOG=1 python src/openpower/decoder/isa/test_caller_svp64_pospopcount.py &> log"$i".txt; do echo "$i passed"; done; while sleep 1; do echo "$i error"; done)& done

since I can't reproduce it, we can look at your log:
(In reply to Luke Kenneth Casson Leighton from comment #0)
> .long 0x05402000 .long
>    ABSOLUTELY SHOULD NOT BE HAPPENING >>> svp64 <<< sim-execute 0x1c addi
> 6,0,0

0x1C on that commit is sv.addi *24, 0, 0 on line 49:
https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_pospopcount.py;h=8c73ce7162d0f1b69a1ee5c3f2565c2c85ce481e;hb=b427a6cc523dc5a277d0e379848e4bad90568592#l49

0x1C being a svp64 instruction is correct there.

(In reply to Jacob Lifshay from comment #5)
> (In reply to Jacob Lifshay from comment #1)
> > which commit produces this?

if you can give me a commit to test on, feel free to reopen.