[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #7 from Andreas Arnez --- Since this is a fairly trivial fix and there haven't been any more comments, I've pushed this as 8229569cb8b1d564a -- s390: Fix VFLRX and WFLRX instructions -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991 --- Comment #6 from Jesus Checa --- (In reply to Andreas Arnez from comment #3) > 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. Oh, I understand now. Thanks for the clarification! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991
--- Comment #5 from Andreas Arnez ---
(In reply to Mark Wielaard from comment #4)
> OK, but does that mean that "vflr" isn't a real opcode because it doesn't
> define on what format it operates?
Basically yes. Well, strictly speaking, the opcode only consists of the
encoded instruction's (E7C5) first and last bytes in this case.
So while this byte sequence correctly specifies the vflr instruction, it
violates the instruction's specification -- hence the specification
exception. On Linux this raises SIGILL, same as if the opcode itself was
unrecognized.
> 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");
Yeah, it's arguable that it shouldn't. The advantage is that future
extensions can be used even without explicit binutils support. Sometimes
this comes in handy, and the risk of misuse is fairly low. For instance,
if a future extension supported rounding down from long to short format,
you could already express this by specifying m3 = 2.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991
Mark Wielaard changed:
What|Removed |Added
Ever confirmed|0 |1
Status|REPORTED|CONFIRMED
--- Comment #4 from Mark Wielaard ---
(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.
[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991 Mark Wielaard changed: What|Removed |Added CC||m...@klomp.org -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991 --- Comment #3 from Andreas Arnez --- (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. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991
Jesus Checa changed:
What|Removed |Added
CC||jch...@redhat.com
--- Comment #2 from Jesus Checa ---
I've tested this patch with the following source:
-
int main(){
asm("wflrx %v0,%v0,0,0");
return 0 ;
}
-
Built with "gcc -march=z14 main.c -o main" and tested with a valgrind build
that contains this patch. Now valgrind works correctly and doesn't report "IR:
specification exception" anymore.
I wanted to do a bit more in-depth testing and I moved to another instruction,
so I changed my program to this one:
-
int main(){
asm("vflr %v0,%v0,0,0,0");
return 0 ;
}
-
Building and running the same way as the aforementioned, this executable will
make that valgrind prints again a specification exception message such as this:
vex s390->IR: specification exception: E700 00C5
==52001== valgrind: Unrecognised instruction at address 0x1000558.
Checking s390x opcodes, it feels like s390_irgen_VFLR is missing the case for
when m3 == 0 (provided my inline asm is right).
I did the same test with VFLL (e700 xxc4) opcodes with the same result,
VFLL instruction makes valgrind report a specification exception, whereas
VFLLS/WFLLS/WFLLD instructions work correctly.
FTR, this is the link where I checked the opcodes:
https://fossies.org/linux/binutils/opcodes/s390-opc.txt
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991 --- Comment #1 from Andreas Arnez --- Created attachment 145141 --> https://bugs.kde.org/attachment.cgi?id=145141=edit Fix VFLRX instruction The problem was due to a typo in s390_irgen_VFLR. This fixes the typo. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447991] s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991 Andreas Arnez changed: What|Removed |Added Assignee|jsew...@acm.org |ar...@linux.ibm.com -- You are receiving this mail because: You are watching all bug changes.
