https://bugs.kde.org/show_bug.cgi?id=509517
Bug ID: 509517
Summary: s390x: Even/odd lane confusion in various vector insns
Classification: Developer tools
Product: valgrind
Version First unspecified
Reported In:
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: vex
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Each of the "vector multiply" instructions VME, VMO, VMLE, VMLO as well as
the "vector multiply and add" instructions VMAE, VMAO, VMALE, VMALO
multiply the corresponding even or odd lanes of two input vectors and
generate a double-wide result.
Now there's confusion in Valgrind about what "even" and "odd" means in
this context. While the architecture specifies big-endian lane numbering
(highest lane=zero), Valgrind IROps such as Iop_MullEven32Ux4 are supposed
to behave exactly the other way around. (See the comment in libvex_ir.h,
which states "lowest lane=zero".) However, the s390x-specific IR
translation as well as the code generation ignore this and behave as if
Iop_MullEven32Ux4 operated on the higher lanes.
While the calculated result is not affected by this discrepancy, the
tracking of undefined bits with memcheck is. Thus, if VME is invoked on
two vectors whose lower lanes are uninitialized and the result vector is
used, memcheck complains:
==57866== Use of uninitialised value of size 8
==57866== at 0x10005F0: depend_on (vme.c:15)
==57866== by 0x1000977: test_vme_2 (vme.c:62)
==57866== by 0x1001055: do_valid (vme.c:76)
==57866== by 0x10011CF: main (vme.c:99)
--
You are receiving this mail because:
You are watching all bug changes.
