Fix some verbiage.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3029 8f6e269a-dfd6-0310-a8e1-e2731360e62c
Encountering a PFPO insn in a client program while running on a host
that does not have that insn now causes an emulation error.
Previously, it caused a failing assertion which was incorrect.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3030 8f6e269a-dfd6-0310-a8e1-e2731360e62c
DFP insns should cause an emulation failure if the host cannot
execute them. Previously, they caused a failing assertion
which was incorrect.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3031 8f6e269a-dfd6-0310-a8e1-e2731360e62c
Add a few more asserts. Fix a function prototype.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3032 8f6e269a-dfd6-0310-a8e1-e2731360e62c
Export s390_host_hwcaps in LibVEX_Translate, so we can use it in
are_valid_hwcaps.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3033 8f6e269a-dfd6-0310-a8e1-e2731360e62c
The long displacement facility is now required. There were a
few spots in the code where this was assumed implicitly.
Ugly fixes were possible, but requiring this facility is not
unreasonable as it has been around sind 2003. So let's just
do this.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3034 8f6e269a-dfd6-0310-a8e1-e2731360e62c
Update x86 decoder as per advise from Julian.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3035 8f6e269a-dfd6-0310-a8e1-e2731360e62c
Fix incorrect implementation of AESKEYGENASSIST in the case where
the two registers are the same.  Fixes #341698.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3036 8f6e269a-dfd6-0310-a8e1-e2731360e62c
New function vfatal which should be used for user messages
to indicate a situation that can legitimately occur but that
we cannot handle today. The function does not return.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3037 8f6e269a-dfd6-0310-a8e1-e2731360e62c
Today this is what happens when we encounter hwcaps we cannot handle:

vex: priv/main_main.c:329 (LibVEX_Translate): Assertion
`are_valid_hwcaps(VexArchAMD64, vta->archinfo_host.hwcaps)' failed.

Running with -d offers this much enlightenment:

--7732:1:main     ... arch = AMD64, hwcaps = INVALID

Not a good base for a bug report...

With this change, the user experience will be smoewhat better, e.g.:

VEX: Support for AVX2 requires AVX capabilities
     Found: amd64-cx16-rdtscp-sse3-avx2
Cannot continue. Good-bye

Specifically, the patch decouples showing hwcaps and deciding their validity.
show_hwcaps_<ARCH> reports the hwcaps it finds. It never returns NULL.
check_hwcaps checks the hwcaps for feasibility and does not return in case
VEX cannot deal with them.
The function are_valid_hwcaps no longer exists.


git-svn-id: svn://svn.valgrind.org/vex/trunk@3038 8f6e269a-dfd6-0310-a8e1-e2731360e62c
Remove some debugging code that was accidentally checked in 
in r3038


git-svn-id: svn://svn.valgrind.org/vex/trunk@3039 8f6e269a-dfd6-0310-a8e1-e2731360e62c