[valgrind] [Bug 450705] s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705 --- Comment #7 from Andreas Arnez --- (In reply to Andreas Arnez from comment #6) > Created attachment 168623 [details] > Updated version of the extension proposal I pushed this now, as a preparation to adding NNPA support. If there are still any issues with this, please let me know. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450705] s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705 --- Comment #6 from Andreas Arnez --- Created attachment 168623 --> https://bugs.kde.org/attachment.cgi?id=168623=edit Updated version of the extension proposal This updated version of the extension proposal addresses the following: * Add a comment that explains the use of guest_IP_AT_SYSCALL for extension handlers. * Ensure that compilation doesn't break on other platforms. * Fix some issues with the PRNO implementation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450705] s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705 --- Comment #4 from Andreas Arnez --- (In reply to Mark Wielaard from comment #3) > Extension idea was posted to the mailinglist: > https://sourceforge.net/p/valgrind/mailman/message/58753610/ Right. I'd like to go ahead with this, if that's OK. There shouldn't be any impact on other platforms at this point, AFAIK, and any potential improvements can likely be performed on top without too much hassle. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 465782] s390x: Valgrind doesn't compile with Clang on s390x
https://bugs.kde.org/show_bug.cgi?id=465782 Andreas Arnez changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andreas Arnez --- I also pushed various patches for the test cases. While I've still seen Clang-specific issues with test case results, at least Valgrind can now be fully built with Clang for s390x. In my view, further test case fixes are out of the scope of this Bug. So I consider this fixed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 472875] none/tests/s390x/dfp-1 failure
https://bugs.kde.org/show_bug.cgi?id=472875 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #6 from Andreas Arnez --- (In reply to Andreas Arnez from comment #3) > Upstream I'd like to fix other issues with the DFP > test cases as well, which will require a much larger patch. I pushed a bunch of patches for the s390x DFP test cases, including a fix for this issue. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 472875] none/tests/s390x/dfp-1 failure
https://bugs.kde.org/show_bug.cgi?id=472875 --- Comment #4 from Andreas Arnez --- Created attachment 160801 --> https://bugs.kde.org/attachment.cgi?id=160801=edit Three-part patch series for fixing some issues in the dfp-1 and pfp test cases This should fix the issue with the condition code, while also fixing a few other issues that require significant adjustments to the output files. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 472875] none/tests/s390x/dfp-1 failure
https://bugs.kde.org/show_bug.cgi?id=472875 --- Comment #3 from Andreas Arnez --- (In reply to Miroslav Franc from comment #2) > Created attachment 160744 [details] > [...] > I just tried it and it seems to work. But, if you already have a fix or > better idea, feel free to ignore it. Your patch should be sufficient for solving this issue. Perhaps for Fedora this can be picked as-is. Upstream I'd like to fix other issues with the DFP test cases as well, which will require a much larger patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 472875] none/tests/s390x/dfp-1 failure
https://bugs.kde.org/show_bug.cgi?id=472875 Andreas Arnez changed: What|Removed |Added Assignee|jsew...@acm.org |ar...@linux.ibm.com --- Comment #1 from Andreas Arnez --- This looks like an issue I noticed while working on Bug 465782: The decimal floating-point instructions for "multiply" and "divide" don't set the condition code, but the test case extracts and prints the condition code anyway without initializing it first. The result could have been random all the time, but has obviously been stable so far. This seems to have changed, probably due to changes in GCC. I've been working on lots of test case fixes anyhow, this one included. Let me sort through my patches, then I can probably come up with a fix soon. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470132] s390x: Assertion failure on VGM instruction
https://bugs.kde.org/show_bug.cgi?id=470132 Andreas Arnez changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Andreas Arnez --- The fix seems important, and it looks like the patches are doing their job, so I pushed them. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470978] s390x: Valgrind cannot start qemu-kvm when "sysctl vm.allocate_pgste=0"
https://bugs.kde.org/show_bug.cgi?id=470978 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Andreas Arnez --- (In reply to Mark Wielaard from comment #4) > The new configure check and tool ldflags addition look good to me. Thanks for checking! I pushed this now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470978] s390x: Valgrind cannot start qemu-kvm when "sysctl vm.allocate_pgste=0"
https://bugs.kde.org/show_bug.cgi?id=470978 --- Comment #3 from Andreas Arnez --- Created attachment 159694 --> https://bugs.kde.org/attachment.cgi?id=159694=edit Build with -Wl,--s390-pgste if the linker supports it This patch should enable building with -Wl,--s390-pgste. I've tested that the Valgrind tools are actually built with that flag on a system where the linker supports this. Note that I have *not* tested running qemu-kvm yet. Also, I'd appreciate if someone with more autoconf knowledge could review this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470978] s390x: Valgrind cannot start qemu-kvm when "sysctl vm.allocate_pgste=0"
https://bugs.kde.org/show_bug.cgi?id=470978 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.
[valgrind] [Bug 471032] s390x: helgrind/tests/tc11_XCHG.c expects code to be at a low address space
https://bugs.kde.org/show_bug.cgi?id=471032 --- Comment #2 from Andreas Arnez --- (In reply to Mark Wielaard from comment #1) > I don't fully understand the s390x assembly, but this fix looks correct to > me. > With the patch the code becomes: > > 1001286: 58 00 20 00 l %r0,0(%r2) > 100128a: ba 01 20 00 cs %r0,%r1,0(%r2) > 100128e: a7 74 ff fc jne 1001286 > > Andreas, do you approve of this fix? Wow, interesting find. Yes, the fix looks good to me, thanks! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470978] New: s390x: Valgrind cannot start qemu-kvm when "sysctl vm.allocate_pgste=0"
https://bugs.kde.org/show_bug.cgi?id=470978 Bug ID: 470978 Summary: s390x: Valgrind cannot start qemu-kvm when "sysctl vm.allocate_pgste=0" Classification: Developer tools Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- qemu-kvm needs the PGSTE mode to be enabled by the kernel. The kernel activates this mode upon exec() when recognizing the s390-specific ELF section PT_S390_PGSTE. Another option is to activate the mode for the whole system (with performance penalty) with the sysctl setting `vm.allocate_psgte'. But when the system-wide setting is not enabled and qemu-kvm is run under Valgrind, the PGSTE mode will not be enabled, leading to a failure like this: ioctl(KVM_CREATE_VM) failed: 22 Invalid argument Host kernel setup problem detected. Please verify: - for kernels supporting the switch_amode or user_mode parameters, whether user space is running in primary address space - for kernels supporting the vm.allocate_pgste sysctl, whether it is enabled qemu-kvm: failed to initialize kvm: Invalid argument -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470132] s390x: Assertion failure on VGM instruction
https://bugs.kde.org/show_bug.cgi?id=470132 --- Comment #2 from Andreas Arnez --- Created attachment 159191 --> https://bugs.kde.org/attachment.cgi?id=159191=edit Enhance test coverage for VGM -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470132] s390x: Assertion failure on VGM instruction
https://bugs.kde.org/show_bug.cgi?id=470132 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.
[valgrind] [Bug 470132] s390x: Assertion failure on VGM instruction
https://bugs.kde.org/show_bug.cgi?id=470132 --- Comment #1 from Andreas Arnez --- Created attachment 159189 --> https://bugs.kde.org/attachment.cgi?id=159189=edit Suggested fix for VGM -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 470132] New: s390x: Assertion failure on VGM instruction
https://bugs.kde.org/show_bug.cgi?id=470132 Bug ID: 470132 Summary: s390x: Assertion failure on VGM instruction Classification: Developer tools Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- A valid VGM instruction can cause Valgrind to exit with an assertion failure like this: vex: priv/guest_s390_toIR.c:16378 (s390_irgen_VGM): Assertion `from <= to' failed. This assertion is incorrect. Instead, the reversed case `from > to' is valid and should result in a wrap-around mask. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 465782] s390x: Valgrind doesn't compile with Clang on s390x
https://bugs.kde.org/show_bug.cgi?id=465782 --- Comment #2 from Andreas Arnez --- (In reply to Andreas Arnez from comment #1) > Created attachment 157848 [details] > Enable compiling Valgrind with clang I pushed the above. Now clang should compile Valgrind for s390x successfully, except for the test cases. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 465782] s390x: Valgrind doesn't compile with Clang on s390x
https://bugs.kde.org/show_bug.cgi?id=465782 --- Comment #1 from Andreas Arnez --- Created attachment 157848 --> https://bugs.kde.org/attachment.cgi?id=157848=edit Enable compiling Valgrind with clang This enables compiling Valgrind with Clang, excluding the s390-specific test cases. I'm working on another patch for the test cases, but that will be more extensive. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 465782] s390x: Valgrind doesn't compile with Clang on s390x
https://bugs.kde.org/show_bug.cgi?id=465782 Andreas Arnez changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 Assignee|jsew...@acm.org |ar...@linux.ibm.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 465782] New: s390x: Valgrind doesn't compile with Clang on s390x
https://bugs.kde.org/show_bug.cgi?id=465782
Bug ID: 465782
Summary: s390x: Valgrind doesn't compile with Clang on s390x
Classification: Developer tools
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: ar...@linux.ibm.com
Target Milestone: ---
When trying to compile Valgrind with Clang on s390x, there are multiple errors:
(1) "scalar-to-vector conversion failed, possible invalid constraint for vector
type" -- in various inline-assemblies where an unsigned long is passed to an
"f" constraint.
(2) "register expected" -- in an inline assembly where the notation "r11" for a
general register is used.
(3) "invalid operand in inline asm: 'svc ${1:b}" -- in an inline assembly where
a "b" modifier is used for a constant.
(4) "__builtin_setjmp is not supported for the current target" -- when
expanding the VG_MINIMAL_SETJMP/LONGJMP macros.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 460356] s390: Sqrt32Fx4 -- cannot reduce tree
https://bugs.kde.org/show_bug.cgi?id=460356 Andreas Arnez changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andreas Arnez --- Pushed all of the above. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 460356] s390: Sqrt32Fx4 -- cannot reduce tree
https://bugs.kde.org/show_bug.cgi?id=460356 --- Comment #2 from Andreas Arnez --- Created attachment 154601 --> https://bugs.kde.org/attachment.cgi?id=154601=edit Patch with fixes and test cases This patch series includes a fix for this issue. It also fixes the implementation of some other vector floating point instructions: * VFMA, VFMS, VFNMA, and VFNMS for 128-bit FP (which were unimplemented) * VFCH and VFCHE (whose implementations were swapped) * VFMIN and VFMAX (which clobbered the condition code) Additionally, the series includes a test case that covers all these issues. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 460356] s390: Sqrt32Fx4 -- cannot reduce tree
https://bugs.kde.org/show_bug.cgi?id=460356 Andreas Arnez changed: What|Removed |Added Assignee|jsew...@acm.org |ar...@linux.ibm.com Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Andreas Arnez --- Assigning to myself. I have a fix, but before attaching it here, I'd like to finish a test case that covers this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 460356] New: s390: Sqrt32Fx4 -- cannot reduce tree
https://bugs.kde.org/show_bug.cgi?id=460356 Bug ID: 460356 Summary: s390: Sqrt32Fx4 -- cannot reduce tree Classification: Developer tools Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- It has been seen that an application running under Valgrind on IBM Z Systems crashes with this message: Sqrt32Fx4(And32(Sub32(0x4:I32,t178),0x3:I32),LDbe:V128(t28)) vex: the `impossible' happened: s390_isel_vec_expr: cannot reduce tree ... Looking at the source, it seems that Sqrt32Fx4 is not implemented correctly. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450705] s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705 --- Comment #2 from Andreas Arnez --- Small update: I'm now considering a different approach that's more similar to the way system calls are handled. Instead of calling a dirty helper, we would have the dispatcher call a guest-specific extension and describe memory effects with the PRE/POST_MEM_* macros. I'm still investigating if this is feasible and how to do that exactly. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450705] s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705 Andreas Arnez changed: What|Removed |Added Status|REPORTED|ASSIGNED Assignee|jsew...@acm.org |ar...@linux.ibm.com Ever confirmed|0 |1 --- Comment #1 from Andreas Arnez --- Created attachment 151228 --> https://bugs.kde.org/attachment.cgi?id=151228=edit Preliminary patch for adding NNPA support This introduces NNPA support, but the memory effects of the NNPA instruction are not represented correctly. In particular this means that memcheck will have false positives as well as false negatives. The current approach uses a dirty helper to implement NNPA. Currently, only a single memory effect can be specified for a dirty helper, and the size is fixed. However, the NNPA instruction behaves more like a subroutine that runs on a separate CPU. It reads and writes various memory regions at dynamic addresses with dynamic sizes. In that regard it might be more comparable with a system call. I mainly attach the patch for illustration purposes. Ideas how to do represent the memory effects correctly are very welcome. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454040] s390x: False-positive memcheck:cond in memmem on arch13 systems
https://bugs.kde.org/show_bug.cgi?id=454040 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Andreas Arnez --- (In reply to Mark Wielaard from comment #8) > Andreas, could you push the fix. Let me know if you want me to add the > testcase separately. Thanks, I pushed the fix now, including your testcase. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454040] s390x: False-positive memcheck:cond in memmem on arch13 systems
https://bugs.kde.org/show_bug.cgi?id=454040 Andreas Arnez changed: What|Removed |Added Attachment #148994|0 |1 is obsolete|| --- Comment #5 from Andreas Arnez --- Created attachment 149025 --> https://bugs.kde.org/attachment.cgi?id=149025=edit Patch for adding a memmem intercept, version 2 This addresses Mark's comment and removes the 'hh' variable. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454040] s390x: False-positive memcheck:cond in memmem on arch13 systems
https://bugs.kde.org/show_bug.cgi?id=454040 --- Comment #4 from Andreas Arnez --- (In reply to Mark Wielaard from comment #2) > Looks good and fixes the issue for me. > I think the for loop could/should be from i = 1. needle being zero sized > (nlen == 0) and n[0] == h[0] (hh != n0) has already been checked above. Thanks, you're right. Also, the hh variable is only accessed once and doesn't improve readability. I'll attach an updated patch. (In reply to Mark Wielaard from comment #3) > Created attachment 149008 [details] > Add memcheck memmem vgtest > > I wrote a testcase that fails before the patch (on s390x) and succeeds > afterwards. It would be nice to add it so we check the same isn't an issue > on other arches and to test our own memmem intercept. Great! Do we also want to check cases where memcheck is expected to complain about the use of uninitialized values in memmem? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454040] s390x: False-positive memcheck:cond in memmem on arch13 systems
https://bugs.kde.org/show_bug.cgi?id=454040 --- Comment #1 from Andreas Arnez --- Created attachment 148994 --> https://bugs.kde.org/attachment.cgi?id=148994=edit Add intercept for memmem on s390x Add an intercept for memmem on s390x platforms. This fixes the problem in my testing. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454040] s390x: False-positive memcheck:cond in memmem on arch13 systems
https://bugs.kde.org/show_bug.cgi?id=454040 Andreas Arnez changed: What|Removed |Added Status|REPORTED|ASSIGNED Assignee|jsew...@acm.org |ar...@linux.ibm.com Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 454040] New: s390x: False-positive memcheck:cond in memmem on arch13 systems
https://bugs.kde.org/show_bug.cgi?id=454040 Bug ID: 454040 Summary: s390x: False-positive memcheck:cond in memmem on arch13 systems Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- On a system that supports the vector enhancements facility 2 (arch13 or higher), glibc runs an optimized version of memmem that uses the "vector string search" instruction. That implementation contains a conditional jump that may depend on undefined values; however, the end result of the function is still independent from these undefined values. Since memcheck can't see that, it may report a false positive, as reproduced like this: $ valgrind perl -e "use lib '.'; require BarXXX;" ... ==3271940== Conditional jump or move depends on uninitialised value(s) ==3271940==at 0x4CAABB6: __memmem_arch13 (memmem-arch13.S:65) ==3271940==by 0x49B64FF: Perl_pp_require (in /usr/lib64/libperl.so.5.32.1) ==3271940==by 0x49654C1: Perl_runops_standard (in /usr/lib64/libperl.so.5.32.1) ==3271940==by 0x48DC3F5: perl_run (in /usr/lib64/libperl.so.5.32.1) ==3271940==by 0x108E37: main (in /usr/bin/perl) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450705] New: s390x: Add NNPA support (arch14)
https://bugs.kde.org/show_bug.cgi?id=450705 Bug ID: 450705 Summary: s390x: Add NNPA support (arch14) Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- Add support for the NNPA facillity introduced with arch14. It includes the instructions nnpa, vclfnh, vclfnl, vcrnf , vcfn, and vcnf. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444552] memcheck/tests/sem fails on s390x with glibc 2.34
https://bugs.kde.org/show_bug.cgi?id=444552 Andreas Arnez changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Andreas Arnez --- Pushed as commit 03a8b24ae362f13c7f97746f72f40240aeb5aade. -- 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 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 444552] memcheck/tests/sem fails on s390x with glibc 2.34
https://bugs.kde.org/show_bug.cgi?id=444552 --- Comment #3 from Andreas Arnez --- Created attachment 146450 --> https://bugs.kde.org/attachment.cgi?id=146450=edit Fix sys_ipc semtimedop for s390x Apart from a potential glibc configuration problem, Valgrind should be fixed as well. So this is a possible fix for the bad invocation of the sys_ipc semtimedop call on s390x platforms. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444552] memcheck/tests/sem fails on s390x with glibc 2.34
https://bugs.kde.org/show_bug.cgi?id=444552 Andreas Arnez changed: What|Removed |Added CC||ar...@linux.ibm.com --- Comment #2 from Andreas Arnez --- (In reply to Mark Wielaard from comment #1) > Note the following in glibc sysdeps/unix/sysv/linux/s390/ipc_priv.h: > [...] > So maybe we are hitting that? But why only with glibc 2.34? You're right that this is different on s390x. And since the difference is not handled in Valgrind, this can't work correctly, and probably never has. But as far as I know, the glibc doesn't normally exploit the sys_ipc variant, but uses the semtimedop syscall instead, if available. It is a bit curious why this would change in a newer glibc. Is there perhaps something wrong with the glibc configuration? -- 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 --- 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 --- 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.
[valgrind] [Bug 447991] New: s390x: Valgrind indicates illegal instruction on wflrx
https://bugs.kde.org/show_bug.cgi?id=447991 Bug ID: 447991 Summary: s390x: Valgrind indicates illegal instruction on wflrx Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- In a Fedora build, it has been seen that Valgrind crashes with illegal instruction when trying to execute the WFLRX instruction: vex s390->IR: specification exception: E700 0008 40C5 ==4036598== valgrind: Unrecognised instruction at address ... See the original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=2035807 WFLRX is a variant of VFLR (vector FP load rounded); it rounds the source vector's first element down from extended format to long format. This variant was introduced with z14. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444481] gdb_server test failures on s390x
https://bugs.kde.org/show_bug.cgi?id=81 Andreas Arnez changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Andreas Arnez --- Applied as commit 99bf5dabf7865aaea7f2192373633e026c6fb16e. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444481] gdb_server test failures on s390x
https://bugs.kde.org/show_bug.cgi?id=81 --- Comment #3 from Andreas Arnez --- (In reply to Andreas Arnez from comment #2) > [...] Note that this shouldn't > affect the AUXV entry for the vDSO, which should still be removed from the > AUXV. Oops, that's not true. This version of the patch leaves the AUXV entry intact as well. Sorry for the confusion. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444481] gdb_server test failures on s390x
https://bugs.kde.org/show_bug.cgi?id=81 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.
[valgrind] [Bug 444481] gdb_server test failures on s390x
https://bugs.kde.org/show_bug.cgi?id=81 --- Comment #2 from Andreas Arnez --- Created attachment 144394 --> https://bugs.kde.org/attachment.cgi?id=144394=edit Keep vDSO mapping on s390x In my testing this patch fixes the issue. Some other architectures already have similar logic to keep the vDSO mapping intact. Note that this shouldn't affect the AUXV entry for the vDSO, which should still be removed from the AUXV. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444481] gdb_server test failures on s390x
https://bugs.kde.org/show_bug.cgi?id=81 Andreas Arnez changed: What|Removed |Added CC||ar...@linux.ibm.com --- Comment #1 from Andreas Arnez --- I've investigated the failure with nlvgdbsigqueue, and here's what I found out so far. The failure happens when trying to continue execution from an unmapped address: +host stacktrace: + at 0x3FFBAF7E480: ??? + by 0x800027FE7: vgPlain_poll (m_libcfile.c:765) + by 0x: ??? It turns out that the failing address, in this case 0x3FFBAF7E480, lies within the address range that previously held the vDSO. The kernel seems to jump there when restarting a "poll" syscall after a signal occurred. But Valgrind doesn't keep the vDSO mapping, so the syscall restart doesn't work and causes a SIGSEGV instead. So, why and since when does the kernel jump to the vDSO? This has obviously been introduced by this s390-specific patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=df29a7440c4b5c65765c8f60396b3b13063e24e9 Considering this change in the kernel's behavior, it now becomes necessary for all user space processes to keep the vDSO mapping intact, and Valgrind currently violates that. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444242] s390x: Valgrind crashes on EXRL with negative offset
https://bugs.kde.org/show_bug.cgi?id=444242 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #3 from Andreas Arnez --- Applied as commit b77dbefe72e4a5c7bcf1576a02c909010bd56991. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444495] dhat/tests/copy fails on s390x
https://bugs.kde.org/show_bug.cgi?id=95 --- Comment #3 from Andreas Arnez --- Created attachment 142946 --> https://bugs.kde.org/attachment.cgi?id=142946=edit Add -fno-builtin to the compile options for dhat/tests/copy This patch avoids the issue by compiling the test case with -fno-builtin, as discussed above. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444495] dhat/tests/copy fails on s390x
https://bugs.kde.org/show_bug.cgi?id=95 Andreas Arnez changed: What|Removed |Added CC||ar...@linux.ibm.com --- Comment #1 from Andreas Arnez --- In my testing Valgrind displays the expected number of bytes copied when "copy" is compiled with -fno-builtin: ==16069== Total: 1,000,181 bytes in 1,012 blocks Perhaps we should add that to the compile flags for this test case? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444242] s390x: Valgrind crashes on EXRL with negative offset
https://bugs.kde.org/show_bug.cgi?id=444242 Andreas Arnez changed: What|Removed |Added Attachment #142769|0 |1 is obsolete|| Assignee|jsew...@acm.org |ar...@linux.ibm.com Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #2 from Andreas Arnez --- Created attachment 142911 --> https://bugs.kde.org/attachment.cgi?id=142911=edit Fix with added test case This version of the patch also adds an EXRL invocation with a negative offset to the "exrl.c" test case. Without the fix, Valgrind crashes when trying to execute this. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444242] s390x: Valgrind crashes on EXRL with negative offset
https://bugs.kde.org/show_bug.cgi?id=444242 --- Comment #1 from Andreas Arnez --- Created attachment 142769 --> https://bugs.kde.org/attachment.cgi?id=142769=edit Sign-extend "relative long" offset in EXRL This fixes the calculation of the "relative long" address in EXRL. The calculation is moved to a helper function addr_rel_long(), which is then used other places as well, wherever applicable. For consistency, the helper function addr_relative() is added as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444242] New: s390x: Valgrind crashes on EXRL with negative offset
https://bugs.kde.org/show_bug.cgi?id=444242 Bug ID: 444242 Summary: s390x: Valgrind crashes on EXRL with negative offset Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- Valgrind's implementation of the "execute relative long" (EXRL) instruction zero-extends the offset instead of sign-extending it. This has been seen to cause a crash with SIGSEGV in s390_irgen_EXRL() when a negative offset occurred. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 441474] vgdb might eat all memory while waiting for sigstop
https://bugs.kde.org/show_bug.cgi?id=441474 Andreas Arnez changed: What|Removed |Added CC||ar...@linux.ibm.com --- Comment #1 from Andreas Arnez --- (In reply to Mark Wielaard from comment #0) > [...] I haven't > identified precisely why valgrind is failing (it is only on s390x during the > gdbserver_tests/nlvgdbsigqueue testcase), [...] Does this mean the test case is failing for you? It isn't for me. If you have more information, I'd look into that. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432387] s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387 Andreas Arnez changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Andreas Arnez --- OK, since there weren't any more comments, I pushed the series upstream, fixing this bug. Regarding the s390_insn_assert macro, please let me know if anyone has a suggestion for a better name. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432387] s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387 --- Comment #8 from Andreas Arnez --- (In reply to Peter Maydell from comment #7) > It seems a bit confusing to me that a function named foo_assert() doesn't do > an assert()... Maybe. I'm open for suggestions for a better name. But since the macro hasn't been introduced by this patch series (it's just used here), I would defer that to a separate patch then. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432387] s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387 --- Comment #6 from Andreas Arnez --- (In reply to Julian Seward from comment #5) > So .. am a bit unclear about this, but it doesn't matter. It's enough to > say that it should be impossible to cause the front end to assert by feeding > it invalid instructions. Instead, all invalid insns should cause a SIGILL > to be handed to the guest (or whatever is appropriate on s390). So long > as the above holds, then I'm happy. Right, this type of decode failure results in a SIGILL to be synthesized, just like with other decode failures. So I think this addresses your concern. I'll apply the patch series then. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432387] s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387
--- Comment #4 from Andreas Arnez ---
(In reply to Julian Seward from comment #3)
> Nice work! The following look OK to land as-is:
> [...]
Great, thanks for reviewing!
> [...]
> Is `misc3` safe to always-build? Or would it require gating on assembler
> features, in the style of "if BUILD_DFP_TESTS .." just below?
>
> .. ah .. later .. I see misc3.c doesn't require any assembler support,
> since it just does `insn rrf,0x" #opcode ",%[out],%[a],%[b],0\n\t"`.
Right, I did consider using z15 mnemonics guarded by a configure switch,
but it just unnecessarily complicated things. So I ended up with this
backwards-compatible approach.
> [...]
> +prog: misc3
>
> Similarly, does this require gating on host hwcaps? Looking at your
> _toIR.c implementation, maybe not, since that appears to be
> down-translating (I mean, translating from the z15 dialect into IR which
> will be re-emitted as instructions for some earlier zSeries CPU). I
> suppose this means that on older platforms, it will be possible to
> compile this test, and run it on V, but not to run it natively.
That's correct. I tested it on z14, and the test succeeded there, even
though the executable crashes without Valgrind.
> [...]
> + s390_insn_assert("vcdlg", m3 == 2 || m3 == 3);
> (multiple times)
> This will fail only on internal logic errors, correct? .. it can't fail only
> because the insn can't be decoded, right?
Actually, the latter. The s390_insn_assert macro passes a special kind of
decoding failure (a "specification exception") up through the call chain
if the asserted condition is not met.
> [...]
> Seeing use of Iop_Perm8x16 made me wonder if it had a definition that
> is independent of the guest/host endianness .. and, no it doesn't:
> libvex_ir.h says:
>
> for i in 0 .. 15 . result[i] = argL[ argR[i] ]
>
> so the meaning of "[n]" is itself ambiguous. Anyways, no need to
> change anything in your code.
OK. I interpreted vec[n] to represent the vector's nth lane (starting
with zero) when split up in 8-bit integer elements. And (at least on
z/Architecture) this happens to be the same as the nth byte of the vector
when stored in memory.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 432387] s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387 Andreas Arnez changed: What|Removed |Added Attachment #136581|0 |1 is obsolete|| --- Comment #2 from Andreas Arnez --- Created attachment 138815 --> https://bugs.kde.org/attachment.cgi?id=138815=edit z15 support This updated patch includes support for both the miscellaneous-instructions-extensions facility 3 and the vector-enhancements facility 2. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 434296] s390x: False-positive memcheck diagnostics from vector string instructions
https://bugs.kde.org/show_bug.cgi?id=434296 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #9 from Andreas Arnez --- (In reply to Julian Seward from comment #8) > Yes, pls land. Looks fine to me. Thanks, pushed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 434296] s390x: False-positive memcheck diagnostics from vector string instructions
https://bugs.kde.org/show_bug.cgi?id=434296 Andreas Arnez changed: What|Removed |Added Attachment #138034|0 |1 is obsolete|| --- Comment #7 from Andreas Arnez --- Created attachment 138170 --> https://bugs.kde.org/attachment.cgi?id=138170=edit Updated patch set For reference, this is the updated patch set with the "verbose" hints added as discussed above. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 434296] s390x: False-positive memcheck diagnostics from vector string instructions
https://bugs.kde.org/show_bug.cgi?id=434296 --- Comment #6 from Andreas Arnez --- (In reply to Julian Seward from comment #5) > [...] I would suggest you do it for all of the > insns covered by this bug, since they look like they could each generate > 20 or more IRStmts per guest insn. OK, done. Unless there's anything else, I'm going to push with this change then. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 434296] s390x: False-positive memcheck diagnostics from vector string instructions
https://bugs.kde.org/show_bug.cgi?id=434296 --- Comment #4 from Andreas Arnez --- (In reply to Julian Seward from comment #3) > Is it possible for any incoming instruction to cause this assertion to > fail? Yes. Of course, only invalid code would do that. > If so that should be reported as SIGILL, and not cause an assertion > failure. Right. The s390_insn_assert macro does not behave like vassert(), though. If its argument is false, it reports a "specification exception" up through the call chain. The user would see something like this: vex s390->IR: specification exception: E712 30F0 F082 ==2699373== valgrind: Unrecognised instruction at address 0x1000518. ... ==2699373== ==2699373== Process terminating with default action of signal 4 (SIGILL): dumping core ... I think it's an improvement over the previous logic, which simply called vassert(). Although in practice, I haven't heard about that causing trouble, either. So my take is, whenever I touch an existing IR translator function that uses vassert() for indicating a specification exception, I replace that by s390_insn_assert() instead. > [...] > The one thing I would suggest is that, for the instructions in question, in > the front end, set the returned DisResult::hint field to Dis_HintVerbose. Ah, good point, will do. Is there a recommended threshold when to set this flag? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433863] s390x: memcheck/tests/s390x/{cds,cs,csg} failures
https://bugs.kde.org/show_bug.cgi?id=433863 Andreas Arnez changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433863] s390x: memcheck/tests/s390x/{cds,cs,csg} failures
https://bugs.kde.org/show_bug.cgi?id=433863 --- Comment #5 from Andreas Arnez --- (In reply to Julian Seward from comment #4) > This seems reasonable to me. Thanks! Applied as d74a637206ef5532ccd2ccb2e31ee2762f184e60. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 434296] s390x: False-positive memcheck diagnostics from vector string instructions
https://bugs.kde.org/show_bug.cgi?id=434296 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.
[valgrind] [Bug 434296] s390x: False-positive memcheck diagnostics from vector string instructions
https://bugs.kde.org/show_bug.cgi?id=434296 --- Comment #2 from Andreas Arnez --- Created attachment 138034 --> https://bugs.kde.org/attachment.cgi?id=138034=edit Fix the memcheck false positives with s390x vector string insns This patch set re-implements the IR transformation of all s390x vector string instructions, fixing all the false positives that I have observed with them. Test cases are added as well. In addition, some improvements to the code generation are made that particularly affect the refactored instructions. Even with the optimizations the generated code can get quite long in some cases. The worst probably being "vector string range compare", where I see up to ca. 1700 s390-insns being emitted. A few instructions, such as VFENE, might be slightly more efficient than before. Suggestions for further improvements are welcome. Note that the patch set is based on the patch for Bug 433863 that removes the s390x-specific compare-and-swap test cases for memcheck. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433863] s390x: memcheck/tests/s390x/{cds,cs,csg} failures
https://bugs.kde.org/show_bug.cgi?id=433863 --- Comment #3 from Andreas Arnez --- (In reply to Andreas Arnez from comment #2) > Created attachment 137982 [details] > Remove memcheck test cases for cs, cds, and csg Any objections/comments? Otherwise I'm planning to apply the patch early next week. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433863] s390x: memcheck/tests/s390x/{cds,cs,csg} failures
https://bugs.kde.org/show_bug.cgi?id=433863 --- Comment #2 from Andreas Arnez --- Created attachment 137982 --> https://bugs.kde.org/attachment.cgi?id=137982=edit Remove memcheck test cases for cs, cds, and csg This is the removal patch. Let me know if I'm missing something. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433863] s390x: memcheck/tests/s390x/{cds,cs,csg} failures
https://bugs.kde.org/show_bug.cgi?id=433863 --- Comment #1 from Andreas Arnez --- (In reply to Mark Wielaard from comment #0) > After the fix some issues (in these tests) can no longer be detected. It is > unclear if that can be fixed. So maybe these tests simply need to be deleted. Right. I don't see an easy way to preserve the behavior that is verified by these tests without re-introducing false positives. So I'll go ahead and remove them. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 434296] s390x: False-positive memcheck diagnostics from vector string instructions
https://bugs.kde.org/show_bug.cgi?id=434296 Andreas Arnez changed: What|Removed |Added Summary|s390x: False-positive |s390x: False-positive |memcheck diagnostics from |memcheck diagnostics from |VSTRC instruction |vector string instructions -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 434296] s390x: False-positive memcheck diagnostics from VSTRC instruction
https://bugs.kde.org/show_bug.cgi?id=434296 --- Comment #1 from Andreas Arnez --- As a heads up, I verified that all vector string instructions currently have the potential to yield memcheck false positives. Thus I'm working on a fix that re-implements all vector string instructions. Instead of implementing them with a dirty helper, they will then be transformed to normal IR instead. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430429] valgrind.h doesn't compile on s390x with clang
https://bugs.kde.org/show_bug.cgi?id=430429 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #10 from Andreas Arnez --- Valgrind 3.17.0 has been released, and it contains the fix for this Bug. See the announcement: https://sourceforge.net/p/valgrind/mailman/message/37246072/ -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 434296] New: s390x: False-positive memcheck diagnostics from VSTRC instruction
https://bugs.kde.org/show_bug.cgi?id=434296 Bug ID: 434296 Summary: s390x: False-positive memcheck diagnostics from VSTRC instruction Product: valgrind Version: 3.15 SVN Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- When using Valgrind's memcheck on s390x for Python, I see the following: $ valgrind python --help ==3451325== Memcheck, a memory error detector ==3451325== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==3451325== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==3451325== Command: python --help ==3451325== ==3451325== Conditional jump or move depends on uninitialised value(s) ==3451325==at 0x4889F82: __internal_ascii_loop_vx (loop.c:336) ==3451325==by 0x4889F82: gconv_transform_internal_ascii_vx (skeleton.c:620) ... The instruction Valgrind complains about is a conditional branch. The condition code has last been updated by the instruction VSTRC (vector string range compare). That instruction has three vector input operands, one of which is only partially initialized and has the remaining bits undefined, so Valgrind probably deduces that the output operand and resulting condition code are undefined as well. But the undefined elements in the vector operand are actually not used by the instruction. The usage of these elements is influenced by corresponding elements in the third input operand. The VSTRC instruction is currently implemented with a dirty helper. This also applies to some other vector string instructions, so those are likely affected by similar issues. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432387] s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387 --- Comment #1 from Andreas Arnez --- Created attachment 136581 --> https://bugs.kde.org/attachment.cgi?id=136581=edit Support miscellaneous-instruction-extensions facility 3 This is the first part of arch13 (=z15) support. It adds support for the miscellaneous-instruction-extensions facility 3. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430429] valgrind.h doesn't compile on s390x with clang
https://bugs.kde.org/show_bug.cgi?id=430429 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED Assignee|jsew...@acm.org |ar...@linux.ibm.com --- Comment #7 from Andreas Arnez --- (In reply to Julian Seward from comment #4) > @Andreas: if the patch works on s390, I think you should land it. Done. Pushed as 484b7dd1e862b1624cb8e7aa453df277da4f7a15. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 433863] s390x: memcheck/tests/s390x/{cds,cs,csg} failures
https://bugs.kde.org/show_bug.cgi?id=433863 Andreas Arnez changed: What|Removed |Added Assignee|jsew...@acm.org |ar...@linux.ibm.com Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||ar...@linux.ibm.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 430429] valgrind.h doesn't compile on s390x with clang
https://bugs.kde.org/show_bug.cgi?id=430429 Andreas Arnez changed: What|Removed |Added CC||ar...@linux.ibm.com --- Comment #2 from Andreas Arnez --- (In reply to Jonathan Albrecht from comment #1) > [...] > I tried the same fix for s390x with: > > diff --git a/include/valgrind.h b/include/valgrind.h > index d33dd3093..04a747c7a 100644 > [...] FWIW, the patch looks OK to me, and I don't see why it shouldn't be sufficient for fixing this error. @Julian: Isn't the patch necessary for other 64-bit platforms as well then? Such as ppc64le or amd64? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432387] s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387 Andreas Arnez changed: What|Removed |Added Assignee|jsew...@acm.org |ar...@linux.ibm.com Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 432387] New: s390x: z15 instructions support
https://bugs.kde.org/show_bug.cgi?id=432387 Bug ID: 432387 Summary: s390x: z15 instructions support Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- Valgrind currently lacks support for the new/enhanced instructions added to z/Architecture with the 13th edition from September 2019 (http://publibfp.dhe.ibm.com/epubs/pdf/a227832c.pdf). Not all new instructions need to be implemented, but only those expected to occur in programs compiled with -march=z15, in particular the new/enhanced instructions from the miscellaneous instruction extensions facility 3 and from the vector enhancements facility 2. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 404076] s390x: z14 vector instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=404076
Andreas Arnez changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Andreas Arnez ---
Based on Julian's feedback on IRC ("ok from me to land") from today, I pushed
this as git commit 159f132289160ab1a5a5cf4da14fb57ecdb248ca.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 429864] s390x: C++ atomic test_and_set yields false-positive memcheck diagnostics
https://bugs.kde.org/show_bug.cgi?id=429864 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Andreas Arnez --- Pushed as 5adeafad7a60b63786d9545e6980de26c17cb0a6. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 429864] s390x: C++ atomic test_and_set yields false-positive memcheck diagnostics
https://bugs.kde.org/show_bug.cgi?id=429864 Andreas Arnez changed: What|Removed |Added Attachment #133842|0 |1 is obsolete|| -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 429864] s390x: C++ atomic test_and_set yields false-positive memcheck diagnostics
https://bugs.kde.org/show_bug.cgi?id=429864 --- Comment #4 from Andreas Arnez --- Created attachment 133881 --> https://bugs.kde.org/attachment.cgi?id=133881=edit [v2] Fix memcheck false positives with compare-and-swap (CS) This version includes the changes from before and uses the `Iop_CasCmp...' operations in other compare-and-swap situations as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 429864] s390x: C++ atomic test_and_set yields false-positive memcheck diagnostics
https://bugs.kde.org/show_bug.cgi?id=429864 --- Comment #3 from Andreas Arnez --- Created attachment 133842 --> https://bugs.kde.org/attachment.cgi?id=133842=edit Fix memcheck false positives with compare-and-swap (CS) Just as a preview, this is a first version of a fix. It only handles CS. A similar fix should be applied to other compare-and-swap variants such as CSG. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 404076] s390x: z14 vector instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=404076 Andreas Arnez changed: What|Removed |Added Attachment #133812|0 |1 is obsolete|| --- Comment #8 from Andreas Arnez --- Created attachment 133841 --> https://bugs.kde.org/attachment.cgi?id=133841=edit [v3] s390x: Support for z14 (arch12) vector instructions Yet another update to the patch. It mainly fixes an issue with the VMSL implementation. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 404076] s390x: z14 vector instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=404076 Andreas Arnez changed: What|Removed |Added Attachment #132244|0 |1 is obsolete|| --- Comment #7 from Andreas Arnez --- Created attachment 133812 --> https://bugs.kde.org/attachment.cgi?id=133812=edit [v2] s390x: Support for z14 (arch12) vector instructions The original patch missed a few minor features. This updated version should complete the functionality required for z14 support. It adds: - VFMIN/VFMAX - VMSL - VBPERM In addition, it introduces a different approach to implementing STFLE. So far unknown (new) facilities were copied from the hardware facilities, even if Valgrind had no handling for them. Since this has caused trouble in the past, the method is changed such that only known features are advertised. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 404076] s390x: z14 vector instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=404076 --- Comment #6 from Andreas Arnez --- (In reply to Julian Seward from comment #5) > Can you use simply IRExpr_Get(offset, Ity_F128) ? If you can, it would give > better performance than doing the two F64 Gets and then joining the results > together. Sorry for the late answer. The current implementation always stores F128 values in floating-point register pairs, even if they originate from vector registers. Thus a GET would have to be split into two operations anyhow. Theoretically this could be improved, e.g., by preferring vector registers for F128 values when the right hardware capabilities are available. I consider this a potential future improvement. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 429864] s390x: C++ atomic test_and_set yields false-positive memcheck diagnostics
https://bugs.kde.org/show_bug.cgi?id=429864
Andreas Arnez changed:
What|Removed |Added
Assignee|jsew...@acm.org |ar...@linux.ibm.com
Status|REPORTED|ASSIGNED
Ever confirmed|0 |1
--- Comment #2 from Andreas Arnez ---
(In reply to Julian Seward from comment #1)
> Yes. There's a special Iop_CasCmpEQ{32,64} or some such, designed
> specifically
> to deal with this problem. See libvex_ir.h for details.
Right I think that should help, thanks for the info. Assigning to myself.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 429864] New: s390x: C++ atomic test_and_set yields false-positive memcheck diagnostics
https://bugs.kde.org/show_bug.cgi?id=429864
Bug ID: 429864
Summary: s390x: C++ atomic test_and_set yields false-positive
memcheck diagnostics
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: vex
Assignee: jsew...@acm.org
Reporter: ar...@linux.ibm.com
Target Milestone: ---
Running the following small test case under Valgrind memcheck on s390x yields
"conditional jump or move depends on uninitialised value(s)" messages:
#include
int main (void)
{
std::atomic_flag af = ATOMIC_FLAG_INIT;
af.test_and_set(std::memory_order_acquire);
}
Valgrind complains about the compare-and-swap instruction CS, then again about
the conditional branch that retries the CS if necessary.
CS operates on an aligned word (4 bytes). It is emitted by the compiler here
even though the atomic variable is only 1 byte in this case. Consequently 3 of
the 4 bytes targeted by CS are uninitialized. However, the outcome of the CS
does *not* depend on the uninitialized bytes, because they are just compared
with copies of themselves. Thus these memcheck errors are false positives.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 428648] s390_emit_load_mem panics due to 20-bit offset for vector load
https://bugs.kde.org/show_bug.cgi?id=428648 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #3 from Andreas Arnez --- Since this is a fairly straightforward (and small) change, I just pushed this as git commit ba73f8d2ebe4b5fe8163ee5ab806f0e50961ebdf. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 428648] s390_emit_load_mem panics due to 20-bit offset for vector load
https://bugs.kde.org/show_bug.cgi?id=428648 --- Comment #2 from Andreas Arnez --- Created attachment 132997 --> https://bugs.kde.org/attachment.cgi?id=132997=edit Force 12-bit amode for vector loads This should fix the issue. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 428648] s390_emit_load_mem panics due to 20-bit offset for vector load
https://bugs.kde.org/show_bug.cgi?id=428648 --- Comment #1 from Andreas Arnez --- Further analysis shows that the offending "load" originates from s390_isel_vec_expr_wrk() while processing an Iex_Load. This function generates the addressing mode with s390_isel_amode() and doesn't ensure that the offset stays within 12 bits. Changing the invocation to s390_isel_amode_short() fixes the problem. Note that this is similar to Bug 417452, where the same issue appeared with "store" instead of "load". -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 428648] New: s390_emit_load_mem panics due to 20-bit offset for vector load
https://bugs.kde.org/show_bug.cgi?id=428648 Bug ID: 428648 Summary: s390_emit_load_mem panics due to 20-bit offset for vector load Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: ar...@linux.ibm.com Target Milestone: --- With a fairly big test program based on Python3, Valgrind was seen to panic with this message: vex: the `impossible' happened: s390_emit_load_mem Where the host stacktrace contains this: ==13902==by 0x8001F3C73: s390_emit_load_mem (host_s390_defs.c:8451) ==13902==by 0x80020A701: emit_S390Instr (host_s390_defs.c:8516) A bit of instrumentation shows that s390_emit_load_mem was invoked with an addressing mode of S390_AMODE_B20, but with a size of 16 bytes. This means that a vector load with 20-bit offset is requested, which is not supported. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 404076] s390x: z14 vector instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=404076 Andreas Arnez changed: What|Removed |Added Ever confirmed|0 |1 Assignee|jsew...@acm.org |ar...@linux.ibm.com Status|REPORTED|CONFIRMED --- Comment #4 from Andreas Arnez --- Created attachment 132244 --> https://bugs.kde.org/attachment.cgi?id=132244=edit s390x: Support for z14 (arch12) vector instructions This is a first version of z14 vector instruction support, as outlined in comment #1. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 419503] s390x: Avoid modifying registers returned from isel functions
https://bugs.kde.org/show_bug.cgi?id=419503 Andreas Arnez changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Andreas Arnez --- Pushed all of the changes proposed above: 6a90a15b9 - s390x: Drop spurious register moves in CDAS instruction selector 4970e2002 - s390x: Fix Iex_Load instruction selectors for F128/D128 types 4e9763c61 - s390x: Introduce and exploit new ALU operator S390_ALU_ILIH 1008ab726 - s390x: Fix typos in comments for sub_from_SP and add_to_SP in isel -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 418997] s390x: Support Iex_ITE for float and vector types
https://bugs.kde.org/show_bug.cgi?id=418997 Andreas Arnez changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Andreas Arnez --- OK, pushed as git commit abe7f083fdebb40c6f4a5adbdd2b64f5c329969a. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 419503] s390x: Avoid modifying registers returned from isel functions
https://bugs.kde.org/show_bug.cgi?id=419503 --- Comment #7 from Andreas Arnez --- See the above attachments for fixes of the findings related to this Bug. -- You are receiving this mail because: You are watching all bug changes.
