https://bugs.kde.org/show_bug.cgi?id=447991
Mark Wielaard <m...@klomp.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|REPORTED |CONFIRMED
--- Comment #4 from Mark Wielaard <m...@klomp.org> ---
(In reply to Andreas Arnez from comment #3)
> (In reply to Jesus Checa from comment #2)
> > ...
> > Checking s390x opcodes, it feels like s390_irgen_VFLR is missing the case
> > for when m3 == 0 (provided my inline asm is right).
> Right, m3 == 0 is not a valid format code. The z/Architecture Principle of
> Operation states:
>
> The M3 field specifies the floating-point format. The floating-point
> format determines the size of the elements within the second operand.
> If a reserved value is specified, a specification exception is
> recognized.
>
> And then declares the values 3 and 4 as representing the long and extended
> formats, respectively, and all other values as reserved.
>
> So I'd say that Valgrind is correct in raising a SIGILL for m3 == 0.
OK, but does that mean that "vflr" isn't a real opcode because it doesn't
define on what format it operates?
Only "vflrd", "wflrd", which operate on longs, and "wflrx", which operate on
extended long, are valid opcodes?
If so, then it is slightly surprising gcc/binutils accepts asm("vflr
%v0,%v0,0,0,0");
--
You are receiving this mail because:
You are watching all bug changes.
