Fixed barrier_next setting

[zohanzephyr]

When testing the “FNSTSW AX” instruction, I found that the results were inconsistent with the x86 instruction. The reason for this is that barrier_next and barrier are not set in native_pass0, while in native_pass “ #if STEP == 0 if(ninst && dyn->insts[ninst-1].x64.barrier_next) { BARRIER(dyn->insts[ninst-1].x64.barrier_next); }

endif “ The if judgment of this code never passes, I think this is problematic, every floating point and FPU status word operation instruction's barrier should be set with its previous instruction's barrier_next, so I made some modifications, but only for the instructions I use for testing, if the modification is reasonable, I will continue to improve it, if the modification is not reasonable, I will continue to improve it, if the modification is not reasonable, I will continue to improve it. , I will continue to improve it, if the modification is not reasonable, you can reject this pull request, but please be aware of this issue, the current “FNSTSW AX” instruction will cause an error.

[zohanzephyr]

@ptitSeb Excuse me, is there any problem with this pr? Please let me know, thanks!

[ptitSeb]

Sorry, I didn't noticed the PR before.

I'm fine with the move of the BARRIER_NEXT macro from beofre INST_EPILOG to after INST_EPILOG, but I don't understand the LAST_BARRIER_NEXT...

[zohanzephyr]

Sorry, I didn't noticed the PR before.

I'm fine with the move of the BARRIER_NEXT macro from beofre INST_EPILOG to after INST_EPILOG, but I don't understand the LAST_BARRIER_NEXT... The meaning of LAST_BARRIER_NEXT is that it sets the previous instruction's barrier_next according to the current instruction.