https://bugs.kde.org/show_bug.cgi?id=495817
--- Comment #8 from Florian Krohm <flo2...@eich-krohm.de> ---
(In reply to Andreas Arnez from comment #7)
> > 4) checks availability of vector opcodes based on hardware capabilities
> > and issues an emulation failure if opcode is not available
> I'm not sure about that one. My thought is that issuing an unsupported
> instruction yields SIGILL on real hardware,
That is not what I observe. This program:
int main(void) { asm volatile("cdlgbr %f1,0,%r2,0"); return 0; }
compiles and runs just fine on my box. Even though CDLGBR requires the
floating-point
extension facility, which I do not have (I presume):
features : esan3 zarch stfle msa ldisp eimm dfp edat etf3eh highgp
rs te vx vxd vxe gs vxe2 vxp sort dflt sie
POP says there is an operation exception if the facility is not installed.
Apparently, the kernel does not seem to translate that into a SIGILL.
> Or is there a general guideline when to use EmFail?
commit c6c2bd4b5eb2d45c66c50c4151080a1060f9306d
Author: Julian Seward <jsew...@acm.org>
Date: Fri Jan 20 14:13:55 2006 +0000
Add Ijk_EmFail, a new kind of IR block exit: an emulation failure
(fatal error) from which Vex (generated code) cannot recover.
s390 is just following suit.
> > 6) For s390_vr_get_n_elem, add a vassert (the mask was already checked
> > earlier). The function used to return 0 for an out-of-range mask
> > which would have made s390_vector_fp_mulAddOrSub to create
> > side-effect-free VEX IR.
> I don't see this. Is this part missing from the patch?
Yes, it is missing, sorry. I wonder... that s390_v3_get_n_elem function has
only one use
and as its body is effectively a one-liner: return 1 << (4 - m);
we can as well inline it and nuke the function. (?)
> There's a typo in s390_irgen_VFPSO, where the mnemonic is misspelled:
> > + s390_insn_assert("vfspo", m3 == 3 || (s390_host_has_vxe && m3 >= 2 &&
> > m3 <= 4));
Yes, good catch!
--
You are receiving this mail because:
You are watching all bug changes.
