[valgrind] [Bug 243483] ppc: callgrind triggers VEX assertion failure
https://bugs.kde.org/show_bug.cgi?id=243483 Carl Love changed: What|Removed |Added CC||c...@linux.ibm.com --- Comment #4 from Carl Love --- Currently this does not seem to fail on a Power 10 system, Fedora release 38, valgrind 3.22 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 --- Comment #10 from Carl Love --- Created attachment 162779 --> https://bugs.kde.org/attachment.cgi?id=162779=edit enable PowerPC testing of Iop_CmpGT* Iops Created patch to add PowerPC testing of the Iop_CmpGT* Iops. Test on top of attachment "Fix vbits for cmpgtExB where E*B==128 rebased onto bb162ac6c". The two patch series was applied on top of commit: commit bd4db67b1d386c352040b1d8fab82f5f3340fc59 (tag: VALGRIND_3_22_0, origin/master, origin/HEAD) Author: Mark Wielaard Date: Tue Oct 31 18:19:05 2023 +0100 -> 3.22.0 final The two patches were tested on Power 10LE, Power9BE/LE and Power 8LE. The memcheck/tests/vbit-test passes on each platform. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025
--- Comment #7 from Carl Love ---
The test for the Iop_CmpGT64Ux2 was changed as follows:
diff --git a/memcheck/tests/vbit-test/irops.c
b/memcheck/tests/vbit-test/irops.c
index a09470905..e94ea2432 100644
--- a/memcheck/tests/vbit-test/irops.c
+++ b/memcheck/tests/vbit-test/irops.c
@@ -861,7 +861,7 @@ static irop_t irops[] = {
{ DEFOP(Iop_CmpGT8Ux16, UNDEF_UNKNOWN), },
{ DEFOP(Iop_CmpGT16Ux8, UNDEF_UNKNOWN), },
{ DEFOP(Iop_CmpGT32Ux4, UNDEF_UNKNOWN), },
- { DEFOP(Iop_CmpGT64Ux2, UNDEF_ALL_64x2), .ppc64 = 1, .ppc32 = 1 },
+ { DEFOP(Iop_CmpGT64Ux2, UNDEF_UNKNOWN), },
{ DEFOP(Iop_Cnt8x16, UNDEF_UNKNOWN), },
{ DEFOP(Iop_Clz8x16, UNDEF_UNKNOWN), },
{ DEFOP(Iop_Clz16x8, UNDEF_UNKNOWN), },
--
The commit was:
commit bb162ac6c082f371da90fb3691f3185a53c2d56f (HEAD -> master, origin/master,
origin/HEAD)
Author: Carl Love
Date: Wed Oct 25 11:20:30 2023 -0400
Change the vbit test specification for Iop_CmpGT64Ux2
The test should be specified as UNDEF_UNKNOWN not UNDEF_ALL_64x2.
No architectures should be enaabled for the test.
This effectively disables the vbit test on all architectures. Note the
Iop_CmpGT* for the other sizes are already set to UNDEF_UNKNOWN. None of the
Iops are getting tested at the current time.
TO DO, work on adding appropriate testing for this class of Iops. Eyal has
started on the new tests.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Carl Love changed: What|Removed |Added Resolution|FIXED |--- Status|CLOSED |REOPENED Ever confirmed|0 |1 --- Comment #4 from Carl Love --- The patch file was all wrong. The commit was reverted. Need to rework the fix. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Carl Love --- Closing -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Carl Love --- Issue resolved. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 --- Comment #1 from Carl Love --- Patch to update the expected results committed. commit 5396fc8d0197e843657736ef8f7d9774400980c9 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Mon Oct 23 19:15:00 2023 -0400 Bug 476025 - Powerpc, update expected results for the vbit-test In commit: commit 26a3abd27db2ef63dafea1ecab00e8239f341f0f Author: Eyal Soha Date: Thu Feb 10 09:52:54 2022 -0700 Bug 432801 - Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals Add support for precise computation of SIMD greater-than on amd64 and x86. This adds support for 64bit, 16bit, and 8bit to the existing 32bit support. The Iop_CmpGT64Ux2 is only supported on PPC32 and PPC64. The above commit adds a more precise method, expensiveCmpGT, for setting the vibits for the Iop_CmpGT64Ux2 Iop. The expected results for the vbit test were not updated to the new more precise results. This patch updates the expected results for the Iop. Patch tested on Power 10. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 476025] New: Vbit expected test results for Iop_CmpGT64Ux2 are wrong.
https://bugs.kde.org/show_bug.cgi?id=476025 Bug ID: 476025 Summary: Vbit expected test results for Iop_CmpGT64Ux2 are wrong. Classification: Developer tools Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- commit 26a3abd27db2ef63dafea1ecab00e8239f341f0f Author: Eyal Soha Date: Thu Feb 10 09:52:54 2022 -0700 Bug 432801 - Valgrind 3.16.1 reports a jump based on uninitialized memory somehow related to clang and signals Add support for precise computation of SIMD greater-than on amd64 and x86. This adds support for 64bit, 16bit, and 8bit to the existing 32bit support. Add a more precise method to calculate the vbit values. The test results for the Iop_CmpGT64Ux2 were not updates. The Iop is only supported on PPC32 and PPC64. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471807] Add support for lazy reading and downloading of DWARF debuginfo
https://bugs.kde.org/show_bug.cgi?id=471807 --- Comment #21 from Carl Love --- I tested the patch on PowerPC BE. Test results: Power 8 BE Ubuntu 20.04.5 LTS (Focal Fossa) pre-lazy-load with Explicitly-load- initialize opd_escn (as of 8/31/2023) (9/18/2023) 742 tests, 743 tests, 743 tests 2 stderr failures, 671 stderr failures,2 stderr failures 0 stdout failures, 152 stdout failures,0 stdout failures 0 stderrB failures, 14 stderrB failures,0 stderrB failures 2 stdoutB failures, 20 stdoutB failures,2 stdoutB failures 9 post failures 43 post failures9 post failures Patch fixes the PowerPC BE issues. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471807] Add support for lazy reading and downloading of DWARF debuginfo
https://bugs.kde.org/show_bug.cgi?id=471807
--- Comment #20 from Carl Love ---
Aaron created a patch to fix the BE failures. It was sent out on Monday Sept
18, subject Re: [Valgrind-developers] ppc64le results
>From 626b205bb9fbe209353b708ace7b22644ca0607a Mon Sep 17 00:00:00 2001
From: Aaron Merey
Date: Mon, 18 Sep 2023 17:42:42 -0400
Subject: [PATCH] Try to find section .opd in read_elf_object
read_elf_debug skips checking for .opd ELF section, causing
assert failures on PPC BE.
This patch adds the missing check for .opd.
---
coregrind/m_debuginfo/readelf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/coregrind/m_debuginfo/readelf.c b/coregrind/m_debuginfo/readelf.c
index 13efc46b8..56a9ce6b2 100644
--- a/coregrind/m_debuginfo/readelf.c
+++ b/coregrind/m_debuginfo/readelf.c
@@ -2883,6 +2883,7 @@ Bool ML_(read_elf_object) ( struct _DebugInfo* di )
#if defined(VGO_solaris)
FIND_MIMG( ".SUNW_ldynsym", ldynsym_escn)
#endif
+ FIND_MIMG( ".opd", opd_escn)
FINDX_MIMG( ".eh_frame", ehframe_escn[ehframe_mix],
do { ehframe_mix++; vg_assert(ehframe_mix <= N_EHFRAME_SECTS);
--
2.41.0
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 471807] Add support for lazy reading and downloading of DWARF debuginfo
https://bugs.kde.org/show_bug.cgi?id=471807 --- Comment #19 from Carl Love --- The ppc patch was tested on a variety of Power Platforms. Here is what I am seeing before the commit to add the lazy loading, with the current Valgrind mainline (includes the lazy commit) and with the patch to fix the lazy load on Power: machine pre-lazy-load current mainlinewith ppc debuginfo fix Power 8 LE 707 tests, 708 tests, 708 tests 4 stderr failures, 280 stderr failures,247 stderr failures, 0 stdout failures, 54 stdout failures, 54 stdout failures, 13 stderrB failures,16 stderrB failures,16 stderrB failures, 0 stdoutB failures, 11 stdoutB failures,12 stdoutB failures 9 post failures 13 post failures9 post failures Power 8 BE 742 tests, 743 tests, 743 tests, 2 stderr failures, 671 stderr failures,671 stderr failures, 0 stdout failures, 152 stdout failures,152 stdout failures, 0 stderrB failures, 14 stderrB failures,14 stderrB failures, 2 stdoutB failures, 20 stdoutB failures,20 stdoutB failures, 9 post failures 43 post failures43 post failures Power 9 LE 711 tests, 712 tests, 712 tests, 4 stderr failures, 280 stderr failures,247 stderr failures, 0 stdout failures, 54 stdout failures, 54 stdout failures, 13 stderrB failures,16 stderrB failures,16 stderrB failures, 0 stdoutB failures, 12 stdoutB failures,12 stdoutB failures 9 post failures 13 post failures9 post failures Power 10 LE 719 tests 720 tests, 720 tests, 2 stderr failures, 42 stderr failures, 2 stderr failures, 0 stdout failures, 0 stdout failures, 0 stdout failures, 2 stderrB failures, 2 stderrB failures, 2 stderrB failures, 10 stdoutB failures,10 stdoutB failures,10 stdoutB failures, 0 post failures 3 post failures 0 post failures -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 471807] Add support for lazy reading and downloading of DWARF debuginfo
https://bugs.kde.org/show_bug.cgi?id=471807 Carl Love changed: What|Removed |Added CC||c...@us.ibm.com --- Comment #17 from Carl Love --- I have been poking around a little on the issue on Power 10 to see what the cause is of the failures this patch seems to be causing. I tried one of the failing tests memcheck/tests/doublefree. valgrind --tool=memcheck -q ./doublefree ==427300== Invalid free() / delete / delete[] / realloc() ==427300==at 0x40A8DD8: free (vg_replace_malloc.c:974) ==427300==by 0x1793: main (doublefree.c:10) ==427300== Address 0x4350040 is 0 bytes inside a block of size 177 free'd ==427300==at 0x40A8DD8: free (vg_replace_malloc.c:974) ==427300==by 0x1793: main (doublefree.c:10) ==427300== Block was alloc'd at ==427300==at 0x40A53F8: malloc (vg_replace_malloc.c:431) ==427300==by 0x176F: main (doublefree.c:8) ==427300== At the moment, it looks like the issue is with freeing memory. There may also be an issue with the debug info stuff but I don't seem to be hitting that yet. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469146] massif --ignore-fn does not ignore inlined functions
https://bugs.kde.org/show_bug.cgi?id=469146 --- Comment #15 from Carl Love --- Paul, I did the following tests on a Power 10 system with Fedora release 36. I ran the mainline Valgrind with the 3.21.0 final commit at the top (commit d97fed7c3e4aa7c910dfa0b6c5de12fd6cf08155 ) The results are: == 714 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdoutB failures, 2 post failures == memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) I then ran your try-massif tree which has 6 of your patches on top of the mainline Valgrine 3.21.0 final commit. So, we have a good base line comparison for your changes. I see the following failures: == 715 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdou\ tB failures, 0 post failures == memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) Both failures also occur in the mainline run. Your branch fixes the massif tests cleanly. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469146] massif --ignore-fn does not ignore inlined functions
https://bugs.kde.org/show_bug.cgi?id=469146 --- Comment #14 from Carl Love --- per comment 10, 11 Paul, I see I cloned GDB not valgrind when trying to install your test tree. Sigh, had spent all day working on a GDB patch and failed to completely switch gears late in the day to look at this issue. Sorry about that. I was able to clone Valgrind and checkout your tree. I am running the full regression tests now and will compare with mainline. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469146] massif --ignore-fn does not ignore inlined functions
https://bugs.kde.org/show_bug.cgi?id=469146 --- Comment #10 from Carl Love --- I cloned a test tree with: git clone git://sourceware.org/git/binutils-gdb.git gdb-test-massif I then looked for the remote git fetch origin git branch -v -a > junk then looked in junk but don't see your tree? Is there some other repository where I should be looking? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469146] massif --ignore-fn does not ignore inlined functions
https://bugs.kde.org/show_bug.cgi?id=469146 --- Comment #3 from Carl Love --- I tried down loading and applying the patch from Paul to the Valgrind mainline. Head of the tree was: commit d97fed7c3e4aa7c910dfa0b6c5de12fd6cf08155 (tag: VALGRIND_3_21_0, origin/master, origin/HEAD) Author: Mark Wielaard Date: Fri Apr 28 17:30:04 2023 +0200 -> 3.21.0 final With the this commit, i.e. no patch, I get the following results from make regtest on Power 10. == 714 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdou\ tB failures, 2 post failures == memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) With the patch for massif to filter_IPs hadles inline functions, I am seeing new failures on Power 10. = 714 tests, 2 stderr failures, 0 stdout failures, 0 stderrB failures, 0 stdou\ tB failures, 6 post failures == memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) massif/tests/alloc-fns-B (post) massif/tests/deep-B (post) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) The diff output for new-cpp looks unchanged from the base run (i.e. no patch). The diff output for deep-B is as follows: more deep-B.post.diff --- deep-B.post.exp 2023-05-01 16:49:31.458553002 -0400 +++ deep-B.post.out 2023-05-01 18:15:57.327511581 -0400 @@ -46,13 +46,15 @@ 8 3,2643,2643,20064 0 9 3,6723,6723,60072 0 98.04% (3,600B) (heap allocation functions) malloc/new/new[], --alloc-fns, etc. -->98.04% (3,600B) 0x: a5 (deep.c:23) - ->98.04% (3,600B) 0x: a4 (deep.c:24) -->98.04% (3,600B) 0x: a3 (deep.c:25) - ->98.04% (3,600B) 0x: a2 (deep.c:26) -->98.04% (3,600B) 0x: a1 (deep.c:27) - ->98.04% (3,600B) 0x: main (deep.c:35) - +->98.04% (3,600B) 0x: a11 (deep.c:17) + ->98.04% (3,600B) 0x: a10 (deep.c:18) +->98.04% (3,600B) 0x: a9 (deep.c:19) + ->98.04% (3,600B) 0x: a8 (deep.c:20) +->98.04% (3,600B) 0x: a7 (deep.c:21) + ->98.04% (3,600B) 0x: a6 (deep.c:22) +->98.04% (3,600B) 0x: a5 (deep.c:23) + ->98.04% (3,600B) 0x: a4 (deep.c:24) + --- - ntime(B) total(B) useful-heap(B) extra-heap(B) stacks(B) --- - The output for deep-C at first glance looks identical. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 469146] massif --ignore-fn does not ignore inlined functions
https://bugs.kde.org/show_bug.cgi?id=469146
--- Comment #2 from Carl Love ---
Per comment in the Valgrind emailI see what is happening now. The stack in
question is
---
==2756940==at 0x48A4C8C: malloc (vg_replace_malloc.c:431)
==2756940==by 0x58025633: ??? (m_trampoline.S:458)
==2756940==by 0x4007D17: call_init (dl-init.c:70)
==2756940==by 0x4007D17: _dl_init (dl-init.c:117)
==2756940==by 0x40311E7: _dl_start_user (in
/usr/lib/powerpc64-linux-gnu/ld64.so.1)
Note the identical addresses for call_init and _dl_init. I believe that
means that call_init is inlined.
This bit of code in ms_main.c skips over call_init
// top has no fnname => search for the first entry that has a fnname
for (i = *top; i < n_ips && !top_has_fnname; i++) {
top_has_fnname = VG_(get_fnname)(ep, ips[i], );
}
The workaround is to add _dl_init to the ignore functions.
I tried adding the line
prog: new-cpp
vgopts: --stacks=no --time-unit=B --massif-out-file=massif.out
vgopts: --ignore-fn=__part_load_locale --ignore-fn=__time_load_locale
--ignore-fn=dwarf2_unwind_dyld_add_image_hook
+vgopts: --ignore-fn=dl_init
to massif/tests/new-cpp-vgtest, but it did not change the results. Not sure if
I didn't do it correctly?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 469146] massif --ignore-fn does not ignore inlined functions
https://bugs.kde.org/show_bug.cgi?id=469146 Carl Love changed: What|Removed |Added CC||c...@us.ibm.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 398883] valgrind incorrectly assumes ABI on PowerPC based on endianness
https://bugs.kde.org/show_bug.cgi?id=398883 --- Comment #9 from Carl Love --- I looked thru the patch. Nothing jumps out at me as being an issue. But, that doesn't guarantee anything given the assembly and all. I did try to apply the patch to test it but it doesn't apply. So, I would say, update the patch and lets test it on the supported BE and LE systems to make sure the patch doesn't break anything. Test it on the non-standard systems where you want to use it. As long as everything works fine, I wouldn't object to it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444110] priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition
https://bugs.kde.org/show_bug.cgi?id=444110 Carl Love changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Carl Love --- Patch committed. commit 873f3766955c4f5caacc014dbe3d4fa0a4f6f712 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Mon Oct 31 13:29:31 2022 -0400 Bug 444110 priv/guest_ppc_toIR.c: warning: duplicated 'if' condition The compiler reported a duplicated condition in VEX/priv/guest_ppc_toIR.c The handling of the plbz and xxpermx instructions have the same if/elseif conditions. The else if condition for the plbz instruction was wrong. The elseif statement should be checking for pType2 not pType1. The plbz instruction was inadvertently being handled by the else statement for the lbz instruction. This patch fixes the checking for the plbz and lbz instructions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444110] priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition
https://bugs.kde.org/show_bug.cgi?id=444110 Carl Love changed: What|Removed |Added CC||will_schm...@vnet.ibm.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444110] priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition
https://bugs.kde.org/show_bug.cgi?id=444110
Carl Love changed:
What|Removed |Added
Status|REPORTED|CONFIRMED
Ever confirmed|0 |1
--- Comment #4 from Carl Love ---
The current code:
if (is_prefix && ( ptype == pType1 ) ) {
if ( !(allow_isa_3_1) ) goto decode_noIsa3_1;
// splat instructions: xxpermx
if (dis_vector_permute_prefix( prefix, theInstr, abiinfo ))
goto decode_success;
} else if (is_prefix && ( ptype == pType1 ) ) { // plbz: load
instruction
if ( !(allow_isa_3_1) ) goto decode_noIsa3_1;
if (dis_int_load_prefix( prefix, theInstr ))
goto decode_success;
} else { // lbz: load instruction
if (dis_int_load_prefix( prefix, theInstr ))
goto decode_success;
}
The above code is wrong. The else if should be checking for the plbz
instruction. The plbz instruction is pType2 not 1.The else if case fails
for the plbz instruction and we hit the else statement. The else statement is
supposed to only succeed for the lpz instruction. However, it is actually
handling both the plbz and lbz instructions. The same function
dis_int_load_prefix() handles both the prefix and non-prefixed versions of the
instruction. They are distinquished by the prefix argument. The else
statement should only succeed for the lbz instruction, i.e. not a prefixed
instruction. So we really have two errors, the else if should check for pType2
and the else should really be else if (!prefix).
The code should be:
if (is_prefix && ( ptype == pType1 ) ) {
if ( !(allow_isa_3_1) ) goto decode_noIsa3_1;
// splat instructions: xxpermx
if (dis_vector_permute_prefix( prefix, theInstr, abiinfo ))
goto decode_success;
} else if (is_prefix && ( ptype == pType2 ) ) { // plbz: load
instruction
if ( !(allow_isa_3_1) ) goto decode_noIsa3_1;
if (dis_int_load_prefix( prefix, theInstr ))
goto decode_success;
} else if (!is_prefix) { // lbz: load instruction
if (dis_int_load_prefix( prefix, theInstr ))
goto decode_success;
}
Tested the original code and verified the else was handling both the prefixed
and non-prefixed lbz instructions. Tested the correct code to verify that the
prefixed instruction matches is_prefix and ptype == pType2. Ran the
regression tests to verify the correct code does not introduce any failures.
In this case, I just got lucky and the code did the right thing in spite of the
coding error. Better to be lucky than good! :-)
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 444110] priv/guest_ppc_toIR.c:36198:31: warning: duplicated 'if' condition
https://bugs.kde.org/show_bug.cgi?id=444110 --- Comment #3 from Carl Love --- Thanks for bringing this to my attention. Yes, something looks wrong. I think there is an issue with the condition, will need to look at it a bit more. Don't think removing the if statement is correct. I will work on it shortly, just getting back from vacation at the moment. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 458845] PowerPC: The L field for the dcbf and sync instruction should be 3 bits in ISA 3.1
https://bugs.kde.org/show_bug.cgi?id=458845 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 458845] PowerPC: The L field for the dcbf and sync instruction should be 3 bits in ISA 3.1
https://bugs.kde.org/show_bug.cgi?id=458845 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Carl Love --- Patch to fix the issue committed. commit 6658311aef8c1a604edb34f2763e83b25882e01b (HEAD -> master) Author: Carl Love Date: Wed Sep 7 11:59:03 2022 -0500 PowerPC: Fix the L field for the sync and dcbf instructions. The L field for the sync and dcbf instructions are three bits wide starting with ISA 3.1. The L field is two bits wide prior to ISA 3.1. Patch based on patches from Shivaprasad Bhat -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 458845] PowerPC: The L field for the dcbf and sync instruction should be 3 bits in ISA 3.1
https://bugs.kde.org/show_bug.cgi?id=458845 Carl Love changed: What|Removed |Added Summary|The L field for the dcbf|PowerPC: The L field for |and sync instruction should |the dcbf and sync |be 3 bits in ISA 3.1|instruction should be 3 ||bits in ISA 3.1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 458845] New: The L field for the dcbf and sync instruction should be 3 bits in ISA 3.1
https://bugs.kde.org/show_bug.cgi?id=458845 Bug ID: 458845 Summary: The L field for the dcbf and sync instruction should be 3 bits in ISA 3.1 Product: valgrind Version: 3.18.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- The L field is two bits wide for the sync and dcbf instruction in ISA 3.0 and older. It changes to three bits in ISA 3.1. The dcbf and sync instructions are only extracting two bits for ISA 3.1. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 --- Comment #9 from Carl Love --- FIx for 32-bit systems committed. commit bc4dc04d5f23e363a79bade6dee475e9c2287c93 (HEAD -> master) Author: Carl Love Date: Mon Apr 4 21:31:33 2022 -0400 Powerpc 32bit, fix the vbpermq support Passing the two 128-bit vA and vB arguments doesn't work in 32-bit mode. The clean helper was changed to compute the result for 8 indexes. The helper is then called twice to get the result for the upper 64-bits of the vB register and the lower 64-bits of the vB register. The patch is an additional fix for bugzilla 451827. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 --- Comment #8 from Carl Love --- Fix for 32-bit systems was tested on Power 8 BE, 32-bit and 64-bit, Power 8 LE 84-bit, Power 9, Power 10. No regressions were found. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 --- Comment #7 from Carl Love --- Created attachment 147972 --> https://bugs.kde.org/attachment.cgi?id=147972=edit Fix for 32-bit Powerpc The patch fixes the instruction support on 32-bit Powerpc. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 Carl Love changed: What|Removed |Added Ever confirmed|0 |1 Status|CLOSED |REOPENED Resolution|FIXED |--- --- Comment #6 from Carl Love --- Issue found with Powerpc 32-bit. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #5 from Carl Love --- Patch committed to Valgrind mainline commit 00017cda521fb3aa3e5d8b892941dbb6bd6c3c25 (HEAD -> master) Author: Carl Love Date: Wed Mar 23 13:41:16 2022 -0500 Powerpc, re-implement the vbpermq instruction support The instruction support generates too many Iops when multiple vbpermq instructions occur together in the binary. This patch changes the implementation to use a clean helper and thus avoid overflowing the internal Valgrind buffer. bugzilla 451827 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 Carl Love changed: What|Removed |Added Assignee|jsew...@acm.org |c...@us.ibm.com --- Comment #3 from Carl Love --- Created attachment 147709 --> https://bugs.kde.org/attachment.cgi?id=147709=edit patch to re-implement the vbpermq instruction using a clean helper The attached patch against current Valgrind mainline changes the support for the vbpermq instruction from using just Iops to use a clean helper. The clean helper significantly reduces the number of Iops thus allowing a series of multiple vbpermq instructions to be decoded without overflowing the Valgrind buffer. Please pull down the Valgrind mainline tree, apply the patch and test it on your application to make sure it works for me. Contact me if you need help with building a patched version of Valgrind. Please let me know if you see any additional issues with this patch. Assuming everything is fine, I will commit the patch to mainline. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 451827] [ppc64le] VEX temporary storage exhausted with several vbpermq instructions
https://bugs.kde.org/show_bug.cgi?id=451827 --- Comment #2 from Carl Love --- Yes, it is probably generating too many iops. I will need to re-implement the support with a clean helper. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450025] ACC file not implemented as a logical overlay of the VSR registers.
https://bugs.kde.org/show_bug.cgi?id=450025 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450025] ACC file not implemented as a logical overlay of the VSR registers.
https://bugs.kde.org/show_bug.cgi?id=450025 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #2 from Carl Love --- Patch committed to fix the issue commit 193ced6bb34a49b5b41756b2c8616e392295328c Author: Carl Love Date: Tue Feb 8 17:52:33 2022 -0600 Powerpc: Update ACC support to reflect being mapped over vsr registers The ISA 3.1 implemention provides the effect of ACC and VSRs logically containing the same data.Future versions of the hardware may define new state or redefine the backing state of the registers. This reworks the code to support the ACC as implemented as a logical mapping over the VSR registers, and lays groundwork for a future implementation utilizing a separate register file. There is a single boolean variable, ACC_mapped_on_VSR, that can be set in disInstr_PPC_WRK(), based on the ISA being used, to select which implementation model to use. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450536] Powerpc: valgrind throws 'facility scv unavailable exception'
https://bugs.kde.org/show_bug.cgi?id=450536 --- Comment #3 from Carl Love --- Patch committed commit 7f11271403219d21c46e3b831cc1709336e792f1 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Fri Feb 11 14:07:20 2022 -0600 Powerpc: Fix checking for scv support, add check to scv instruction parsing. The check for the scv instruction in coregrind/m_machine.c issues an scv instruction and uses sigill to determine if the instruction is supported. Issuing scv on systems that don't support scv, i.e. scv support is not in HWCAPS2, generates a message in dmesg "Facility 'SCV' unavailable (12), exception". This patch removes the sigill based scv instruction test from coregrind/m_machine.c. The scv support is now determined by reading the HWCAPS2 in setup_client_stack(). VG_(machine_ppc64_set_scv_support) is called to set the flag ppc_scv_supported in struct VexArchInfo. The allow_scv flag is added in disInstr_PPC_WRK. The allow_scv flag is used to ensure the host has support for scv before generating the iops for the scv instruction. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447995] Valgrind segfault on power10 due to hwcap checking code
https://bugs.kde.org/show_bug.cgi?id=447995 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450536] Powerpc: valgrind throws 'facility scv unavailable exception'
https://bugs.kde.org/show_bug.cgi?id=450536 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450536] Powerpc: valgrind throws 'facility scv unavailable exception'
https://bugs.kde.org/show_bug.cgi?id=450536 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Carl Love --- patch committed commit 7f11271403219d21c46e3b831cc1709336e792f1 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Fri Feb 11 14:07:20 2022 -0600 Powerpc: Fix checking for scv support, add check to scv instruction parsing. The check for the scv instruction in coregrind/m_machine.c issues an scv instruction and uses sigill to determine if the instruction is supported. Issuing scv on systems that don't support scv, i.e. scv support is not in HWCAPS2, generates a message in dmesg "Facility 'SCV' unavailable (12), exception". This patch removes the sigill based scv instruction test from coregrind/m_machine.c. The scv support is now determined by reading the HWCAPS2 in setup_client_stack(). VG_(machine_ppc64_set_scv_support) is called to set the flag ppc_scv_supported in struct VexArchInfo. The allow_scv flag is added in disInstr_PPC_WRK. The allow_scv flag is used to ensure the host has support for scv before generating the iops for the scv instruction. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450536] Powerpc: valgrind throws 'facility scv unavailable exception'
https://bugs.kde.org/show_bug.cgi?id=450536 Carl Love changed: What|Removed |Added Summary|valgrind throws 'facility |Powerpc: valgrind throws |scv unavailable exception' |'facility scv unavailable ||exception' -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450536] valgrind throws 'facility scv unavailable exception'
https://bugs.kde.org/show_bug.cgi?id=450536 --- Comment #1 from Carl Love --- Created attachment 146924 --> https://bugs.kde.org/attachment.cgi?id=146924=edit Powerpc fix checking for scv support add check for scv instruction The attached patch fixes the issue of testing the scv instruction which results in an entry in dmesg. It also adds the missing check for scv support in VEX/priv/guest_ppc_toIR.c, function dis_syslink(). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450536] New: valgrind throws 'facility scv unavailable exception'
https://bugs.kde.org/show_bug.cgi?id=450536 Bug ID: 450536 Summary: valgrind throws 'facility scv unavailable exception' Product: valgrind Version: 3.18.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- 'valgrind ls' command throws "Facility 'SCV' unavailable (12), exception at 0x5806aad0, MSR=8280f033", on kernel where SCV support is not there. Contact Information = nasas...@in.ibm.com ---uname output--- Linux ltcden14-lp8 4.18.0-359.el8.bz196163.ppc64le #1 SMP Sat Jan 29 01:35:20 EST 2022 ppc64le ppc64le ppc64le GNU/Linux Machine Type = IBM,9080-HEX ---Debugger--- A debugger is not configured ---Steps to Reproduce--- 1. Install valgrind-3.18.1-6.el8.ppc64le if not installed 2. Run 'valgrind ls' command 3. Check the 'dmesg' ... Facility 'SCV' unavailable (12), exception at 0x5806aad0, MSR=8280f033 [root@ltcden14-lp8 ~]# LD_SHOW_AUXV=1 /bin/true AT_DCACHEBSIZE: 0x80 AT_ICACHEBSIZE: 0x80 AT_UCACHEBSIZE: 0x0 AT_SYSINFO_EHDR: 0x7fffbacb AT_??? (0x28): 0xc000 AT_??? (0x29): 0x60080 AT_??? (0x2a): 0x8000 AT_??? (0x2b): 0x80080 AT_??? (0x2c): 0x10 AT_??? (0x2d): 0x80080 AT_??? (0x2e): 0x40 AT_??? (0x2f): 0x100080 AT_HWCAP:true_le archpmu vsx arch_2_06 dfp ic_snoop smt mmu fpu altivec ppc64 ppc32 AT_PAGESZ: 65536 AT_CLKTCK: 100 AT_PHDR: 0x13bd60040 AT_PHENT:56 AT_PHNUM:9 AT_BASE: 0x7fffbacd AT_FLAGS:0x0 AT_ENTRY:0x13bd61a7c AT_UID: 0 AT_EUID: 0 AT_GID: 0 AT_EGID: 0 AT_SECURE: 0 AT_RANDOM: 0x7fffdf1bb070 AT_HWCAP2: mma arch_3_1 darn ieee128 arch_3_00 vcrypto tar isel ebb dscr arch_2_07 AT_EXECFN: /bin/true AT_PLATFORM: power10 AT_BASE_PLATFORM:power10 [root@ltcden14-lp8 ~]# grep model /proc/cpuinfo model : IBM,9080-HEX Userspace tool common name: valgrind Userspace rpm: valgrind-3.18.1-6.el8.ppc64le The userspace tool has the following bit modes: 64-bit Userspace tool obtained from project website: na -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450025] ACC file not implemented as a logical overlay of the VSR registers.
https://bugs.kde.org/show_bug.cgi?id=450025 --- Comment #1 from Carl Love --- Created attachment 146589 --> https://bugs.kde.org/attachment.cgi?id=146589=edit Patch to change ACC to overlay VSRs Initial ACC support was implemented to use a separate register file, but in practice (ISA 3.1) the hardware implementation logically overlays over the existing VSR registers. This may change in future hardware, so the current implementation assumes ACC and VSRs logically contain the same data, but code remains in place to support future implementations that may require a separate register file. The patch reworks the code to support the ACC as implemented as a logical mapping over the VSR registers, and lays groundwork for a future implementation utilizing a separate register file. There is a single boolean variable, ACC_mapped_on_VSR, that can be set in disInstr_PPC_WRK(), based on the ISA being used, to select which implementation model to use. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 450025] New: ACC file not implemented as a logical overlay of the VSR registers.
https://bugs.kde.org/show_bug.cgi?id=450025 Bug ID: 450025 Summary: ACC file not implemented as a logical overlay of the VSR registers. Product: valgrind Version: 3.18.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- The ACC support in ISA 3.1 is supposted to be done as a logical overlay of the VSR registers. The initial implementation was done as a physically separate register file. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 449672] ppc64 --track-origins=yes causes failures because of bad cmov addHRegUse
https://bugs.kde.org/show_bug.cgi?id=449672 --- Comment #1 from Carl Love --- Mark, thanks for letting us know about the issue. Let us know if there is anything we can do to help verify the fix. Off hand I have nothing to add to the fix. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 449483] Powerpc: vcmpgtsq., vcmpgtuq,, vcmpequq. instructions not setting the condition code correctly
https://bugs.kde.org/show_bug.cgi?id=449483 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Carl Love --- closing -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 449483] Powerpc: vcmpgtsq., vcmpgtuq,, vcmpequq. instructions not setting the condition code correctly
https://bugs.kde.org/show_bug.cgi?id=449483 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Carl Love --- Patches committed to Valgrind mainline. commit ab740a1741322b6d0a02ea00499c2497e35e7022 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Tue Feb 1 21:22:37 2022 + Powerpc test_isa_3_1_VRT fix The vcmpequq, vcmpgtsq, vcmpgtuq test cases for the dotted versions of the instructions were issuing the non-dotted instruction. This patch fixes the issues and updates the expected output. Note, the issue exposed a bug in the VEX/priv/guest_ppc_toIR.c handling of the instructions. That fix is in a separate patch. commit 27fc72dfb185733fed3dfd974ad2e7c5476852f6 Author: Carl Love Date: Tue Feb 1 21:29:30 2022 + Fix setting condition code for Vector Compare quad word instructions. The vcmpgtsq., vcmpgtuq,, vcmpequq. instructions set the condition code field 6 to 0b1000 for true, 0b0010 for false. The condition code was being set according to the typical condition code values for equal and greater than which is incorrect for these instructions. The patch fixes the setting of the condition code as specified in the instructions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 449483] Powerpc: vcmpgtsq., vcmpgtuq,, vcmpequq. instructions not setting the condition code correctly
https://bugs.kde.org/show_bug.cgi?id=449483 --- Comment #2 from Carl Love --- Created attachment 146155 --> https://bugs.kde.org/attachment.cgi?id=146155=edit Powerpc VEX fix for vcmpgtsq., vcmpgtuq,, vcmpequq. opcode calculation The patch fixes the calculation for the condition code for the three instructions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 449483] Powerpc: vcmpgtsq., vcmpgtuq,, vcmpequq. instructions not setting the condition code correctly
https://bugs.kde.org/show_bug.cgi?id=449483 --- Comment #1 from Carl Love --- Created attachment 146154 --> https://bugs.kde.org/attachment.cgi?id=146154=edit Powerpc test fixes, updated expected results The patch fixes the missing dot in the instruction opcodes. The expected results file is also updated. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 449483] New: Powerpc: vcmpgtsq., vcmpgtuq,, vcmpequq. instructions not setting the condition code correctly
https://bugs.kde.org/show_bug.cgi?id=449483 Bug ID: 449483 Summary: Powerpc: vcmpgtsq., vcmpgtuq,, vcmpequq. instructions not setting the condition code correctly Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- The test_isa_3_1_VRT.c test issues the wrong instruction for the test of the vcmpgtsq., vcmpgtuq,, vcmpequq. instructions. The non-dotted instructions are issued. The non-dotted instructions do not set the condition code field. Once the tests were fixed, it exposed an issue in the VEX support where the calculation of the condition code for the three dotted instructions was not correct. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447995] Valgrind segfault on power10 due to hwcap checking code
https://bugs.kde.org/show_bug.cgi?id=447995 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447995] Valgrind segfault on power10 due to hwcap checking code
https://bugs.kde.org/show_bug.cgi?id=447995 --- Comment #2 from Carl Love --- Patch committed commit 3ea8d4327003c3cefe8e82c59be8e92dcfe1a60f (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Fri Jan 14 23:04:44 2022 + Assorted changes to protect from side affects from the feature checking code. Patch contributed by Will Schmidt This problem was initially reported by Tulio, he assisted me in identifying the underlying issue here. This was discovered on a Power10, and occurs since the ISA 3.1 support check uses the brh instruction via a hardcoded ".long 0x7f1401b6" asm stanza. That encoding writes to r20, and since the stanza does not contain a clobber the compiler did not know to save or restore that register upon entry or exit. The junk value remaining in r20 subsequently caused a segfault. This patch adds clobber masks to the instruction stanzas, as well as updates the associated comments to clarify which registers are being used. As part of this change I've also - updated the .long for the cnttzw instruction to write to r20, and zeroed the reserved bits from that instruction so it is properly decoded by the disassembler. - updated the .long for the dadd instruction to write to f0. I've inspected the current codegen with these changes in place, and confirm that r20 is now saved and restored on entry and exit from the machine_get_hwcaps() function. bugzilla 447995 Valgrind segfault on power10 due to hwcap checking code -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 447995] Valgrind segfault on power10 due to hwcap checking code
https://bugs.kde.org/show_bug.cgi?id=447995 Carl Love changed: What|Removed |Added Attachment #145143|0 |1 is obsolete|| --- Comment #1 from Carl Love --- Created attachment 145669 --> https://bugs.kde.org/attachment.cgi?id=145669=edit updated patch to add clobber masks to inline asm statements Updated version of the patch from Will -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444836] PPC: pstq instruction for R=1 is not storing to the correct address
https://bugs.kde.org/show_bug.cgi?id=444836 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444836] PPC: pstq instruction for R=1 is not storing to the correct address
https://bugs.kde.org/show_bug.cgi?id=444836 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444836] PPC: pstq instruction for R=1 is not storing to the correct address
https://bugs.kde.org/show_bug.cgi?id=444836 Carl Love changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444836] PPC: pstq instruction for R=1 is not storing to the correct address
https://bugs.kde.org/show_bug.cgi?id=444836 --- Comment #3 from Carl Love --- The two patches in the attachments have been committed. commit 3950c5d661ee09526cddcf24daf5fc22bc83f70c (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Mon Nov 1 11:18:32 2021 -0500 Valgrind Add powerpc R=1 tests Contributed by Will Schmidt This includes updates and adjustments as suggested by Carl. Add tests that exercise PCRelative instructions. These instructions are encoded with R==1, which indicate that the memory accessed by the instruction is at a location relative to the currently executing instruction. These tests are built using -Wl,-text and -Wl,-bss options to ensure the location of the target array is at a location with a specific offset from the currently executing instruction. The write instructions are aimed at a large buffer in the bss section; which is checked for updates at the completion of each test. In order to ensure consistent output across assorted systems, the tests have been padded with ori, nop instructions and align directives. Detailed changes: * Makefile.am: Add test_isa_3_1_R1_RT and test_isa_3_1_R1_XT tests. * isa_3_1_helpers.h: Add identify_instruction_by_func_name() helper function to indicate if the test is for R==1. Add helpers to initialize and print changes to the pcrelative_write_target array. Add #define to help pad code with a series of eyecatcher ORI instructions. * test_isa_3_1_R1_RT.c: New test. * test_isa_3_1_R1_XT.c: New test. * test_isa_3_1_R1_XT.stdout.exp: New expected output. * test_isa_3_1_R1_XT.stdout.exp: New expected output. * test_isa_3_1_R1_RT.stderr.exp: New expected output. * test_isa_3_1_R1_RT.stderr.exp: New expected output. * test_isa_3_1_R1_RT.vgtest: New test handler. * test_isa_3_1_common.c: Add indicators (updates_byte,updates_halfword, updates_word) indicators to control the output from the R==1 tests. Add helper check for "_R1" to indicate if instruction is coded with R==1. Add init and print helpers for the pcrelative_write_target array. commit ae8c6de01417023e78763de145b1c0e6ddd87277 Author: Carl Love Date: Wed Oct 20 20:40:13 2021 + Fix for the prefixed stq instruction in PC relative mode. The pstq instruction for R=1, was not using the correct effective address. The EA_hi and EA_lo should have been based on the value of EA as calculated by the function calculate_prefix_EA. Unfortuanely, the EA_hi and EA_lo addresses were still using the previous code (not PC relative) to calculate the address from the contants of RA plus the offset. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444836] PPC: pstq instruction for R=1 is not storing to the correct address
https://bugs.kde.org/show_bug.cgi?id=444836 --- Comment #2 from Carl Love --- Created attachment 143141 --> https://bugs.kde.org/attachment.cgi?id=143141=edit New pc relative tests for PPC ISA 3.1 instrucitons The patch adds tests for all of the new ISA 3.1 PC-relative instructions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444836] PPC: pstq instruction for R=1 is not storing to the correct address
https://bugs.kde.org/show_bug.cgi?id=444836 --- Comment #1 from Carl Love --- Created attachment 143140 --> https://bugs.kde.org/attachment.cgi?id=143140=edit patch to fix the pstq R=1 instruction store address Patch to fix the issue -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444836] New: PPC: pstq instruction for R=1 is not storing to the correct address
https://bugs.kde.org/show_bug.cgi?id=444836 Bug ID: 444836 Summary: PPC: pstq instruction for R=1 is not storing to the correct address Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- The pstq instruction with R=1 (PC relative) is using the wrong effective address calculation. The address calculation code was not properly updated to use the EA from the new functions for calculating the address based on the ISA 3.1 R flag. As a result, the instruction with R=1 may or may not segmentation fault depending on the register contents. New regression tests have been developed that allow the PC relative instruction testing. These tests found the issue. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444571] ppc64le dlclose_leak fails (when lxsibzx is used)
https://bugs.kde.org/show_bug.cgi?id=444571 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #16 from Carl Love --- The patch has been committed. commit 6e08ee95f7f1b1c3fd434fa380cc5b2cc3e3f7c7 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Fri Oct 29 16:30:33 2021 -0500 Bug 444571 - PPC, fix the lxsibzx and lxsihzx so they only load their respective sized data. The lxsibzx was doing a 64-bit load. The result was initializing additional bytes in the register that should not have been initialized. The memcheck/tests/linux/dlclose_leak test detected the issue. The code generation uses lxsibzx and stxsibx with -mcpu=power9. Previously the lbz and stb instructions were generated. The same issue was noted and fixed with the lxsihzx instruction. The memcheck/tests/linux/badrw test now passes as well. https://bugs.kde.org/show_bug.cgi?id=444571 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444571] ppc64le dlclose_leak fails (when lxsibzx is used)
https://bugs.kde.org/show_bug.cgi?id=444571 --- Comment #14 from Carl Love --- While fixing the lxsibzx instruction, I noticed the same issue with lxsihzx so fixed it at the same time. Looking at comment #3 I see you called out the lxsihzx instruction in the badrw test. Looks like the patch fixed the badrw test as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444571] ppc64le dlclose_leak fails (when lxsibzx is used)
https://bugs.kde.org/show_bug.cgi?id=444571 --- Comment #13 from Carl Love --- Mark, give the patch a spin and see if it works for you. The test results on my machine show the test is fixed. == 671 tests, 4 stderr failures, 1 stdout failure, 1 stderrB failure, 0 stdoutB f\ ailures, 2 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat(stderr) memcheck/tests/ppc64/power_ISA2_05 (stdout) helgrind/tests/tls_threads (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444571] ppc64le dlclose_leak fails (when lxsibzx is used)
https://bugs.kde.org/show_bug.cgi?id=444571 --- Comment #12 from Carl Love --- Created attachment 143017 --> https://bugs.kde.org/attachment.cgi?id=143017=edit Fix for the lxsibzx and lxsihzx instrutions The attached patch fixes the issues with the memcheck/tests/linux/dlclose_leak test. The issue only occurs on newer compiler with the -mcpu=power9 option which generates the lxsibzx and lxsihzx instructions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444571] ppc64le dlclose_leak fails (when lxsibzx is used)
https://bugs.kde.org/show_bug.cgi?id=444571 Carl Love changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #10 from Carl Love --- I found a Power 10 system with RHEL 9 installed. Looks like there is a compiler change that is now generating the lxsibzx and stxsibx instructions. I am seeing the instructions being generated on this system. Fedora 34 has gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) dlclose_leak dump x = memToLeak[-1]; 1a90: 30 00 3f e9 ld r9,48(r31) 1a94: ff ff 29 89 lbz r9,-1(r9) 1a98: 38 00 3f 99 stb r9,56(r31) int i; for (i = 0; i < 2; ++i) RHEL 9, gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-2) dlclose_leak dump ... x = memToLeak[-1]; 1a94: 30 00 3f e9 ld r9,48(r31) 1a98: ff ff 29 39 addir9,r9,-1 1a9c: 1a 4e 00 7c lxsibzx vs0,0,r9 1aa0: 38 00 3f 39 addir9,r31,56 1aa4: 1a 4f 00 7c stxsibx vs0,0,r9 int i; for (i = 0; i < 2; ++i) The newer gcc is generating the instructions in question. The test results are: == 671 tests, 8 stderr failures, 1 stdout failure, 1 stderrB failure, 0 stdoutB\ failures, 2 post failures == gdbserver_tests/hginfo (stderrB) memcheck/tests/badrw (stderr) memcheck/tests/bug340392 (stderr) memcheck/tests/linux/dlclose_leak-no-keep (stderr) memcheck/tests/linux/dlclose_leak(stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat(stderr) memcheck/tests/ppc64/power_ISA2_05 (stdout) helgrind/tests/free_is_write (stderr) helgrind/tests/tls_threads (stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) The test is failing. I can now reproduce the bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444571] ppc64le dlclose_leak fails (when lxsibzx is used)
https://bugs.kde.org/show_bug.cgi?id=444571 --- Comment #7 from Carl Love --- I have access to a Fedora system with gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) and glib 2.33. When I try to run the binary b I get the message: ./b: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./b) I will look for a system with CentOS 9 system, but that is not a usual one for us to have around. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 444571] ppc64le dlclose_leak fails (when lxsibzx is used)
https://bugs.kde.org/show_bug.cgi?id=444571 --- Comment #4 from Carl Love --- Can you give me some info on your test environment? I have run the regression tests (make regtest) on a Power 9 and a Power 10 system and don't see these errors. I tried testing the current updstream code from git on several systems. Power 9, Ubuntu 20.04 LE == 665 tests, 4 stderr failures, 0 stdout failures, 0 stderrB failures, 1 stdou\ tB failure, 2 post failures == gdbserver_tests/nlcontrolc (stdoutB) memcheck/tests/bug340392 (stderr) memcheck/tests/leak_cpp_interior (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat(stderr) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) Power 10, Ubuntu 21.04 == 672 tests, 3 stderr failures, 1 stdout failure, 0 stderrB failures, 1 stdout\ B failure, 2 post failures == gdbserver_tests/nlcontrolc (stdoutB) memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat(stderr) memcheck/tests/ppc64/power_ISA2_05 (stdout) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) Power 10, Fedora 34 memcheck/tests/bug340392 (stderr) memcheck/tests/linux/rfcomm (stderr) memcheck/tests/linux/sys-execveat(stderr) memcheck/tests/ppc64/power_ISA2_05 (stdout) massif/tests/new-cpp (post) massif/tests/overloaded-new (post) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 411189] Valgrind does not support POWER9 "DARN" RNG instructions
https://bugs.kde.org/show_bug.cgi?id=411189 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Carl Love --- No response from Jack. The bug has been fixed. Closing. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 420780] PPCle erroneous report on strncmp use.
https://bugs.kde.org/show_bug.cgi?id=420780 --- Comment #3 from Carl Love --- Rusty Russell, please verify that the issue is fixed with the current upstream Valgrind source tree. If so, please close the issue. If not, please let us know so we can look into it some more. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 420780] PPCle erroneous report on strncmp use.
https://bugs.kde.org/show_bug.cgi?id=420780 Carl Love changed: What|Removed |Added CC||c...@us.ibm.com Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Carl Love --- Compiled the included test case and ran on the current upstream Valgrind as of 9/1/2021. The test case seems to run fine now. valgrind ./valgrind-420780 ==2869120== Memcheck, a memory error detector ==2869120== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2869120== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info ==2869120== Command: ./valgrind-420780 ==2869120== ==2869120== ==2869120== HEAP SUMMARY: ==2869120== in use at exit: 16 bytes in 1 blocks ==2869120== total heap usage: 1 allocs, 0 frees, 16 bytes allocated ==2869120== ==2869120== LEAK SUMMARY: ==2869120==definitely lost: 16 bytes in 1 blocks ==2869120==indirectly lost: 0 bytes in 0 blocks ==2869120== possibly lost: 0 bytes in 0 blocks ==2869120==still reachable: 0 bytes in 0 blocks ==2869120== suppressed: 0 bytes in 0 blocks ==2869120== Rerun with --leak-check=full to see details of leaked memory ==2869120== ==2869120== For lists of detected and suppressed errors, rerun with: -s ==2869120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0 Compiled the test case wth gcc --version gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 Marking the issue resolved. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 411189] Valgrind does not support POWER9 "DARN" RNG instructions
https://bugs.kde.org/show_bug.cgi?id=411189 --- Comment #6 from Carl Love --- Jack Lloyd, please verify the fix works for you using the current upstream Valgrind repository. If the issue is fixed please close this issue. Otherwise let me know and I will look at it again. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 411189] Valgrind does not support POWER9 "DARN" RNG instructions
https://bugs.kde.org/show_bug.cgi?id=411189 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #5 from Carl Love --- Tested the test program on a Power 9 box with the latest Valgrind source tree. valgrind ./min_darn ==2840566== Memcheck, a memory error detector ==2840566== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2840566== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info ==2840566== Command: ./min_darn ==2840566== 13F736A2E6879909 ==2840566== ==2840566== HEAP SUMMARY: ==2840566== in use at exit: 0 bytes in 0 blocks ==2840566== total heap usage: 1 allocs, 1 frees, 1,024 bytes allocated ==2840566== ==2840566== All heap blocks were freed -- no leaks are possible ==2840566== ==2840566== For lists of detected and suppressed errors, rerun with: -s ==2840566== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) The test program seems to work fine. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 440793] Valgrind ppc64/tests/Makefile.am fixups
https://bugs.kde.org/show_bug.cgi?id=440793 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 440793] Valgrind ppc64/tests/Makefile.am fixups
https://bugs.kde.org/show_bug.cgi?id=440793 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 440793] Valgrind ppc64/tests/Makefile.am fixups
https://bugs.kde.org/show_bug.cgi?id=440793 --- Comment #1 from Carl Love --- Issues were addressed in commit: commit 81032a82f77fc7038d80621fefd75b5726760a60 Author: Carl Love Date: Fri Sep 10 16:20:10 2021 -0500 Cleanup of none/tests/ppc64/Makefile.am Fixing indentation and move the jm_insns_CFLAGS next to the other CFLAGS definitions. No functional changes. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 440906] powerpc valgrind testsuite; update test_isa_3_1_common.c to avoid modulo against hard regs
https://bugs.kde.org/show_bug.cgi?id=440906 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 440906] powerpc valgrind testsuite; update test_isa_3_1_common.c to avoid modulo against hard regs
https://bugs.kde.org/show_bug.cgi?id=440906 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Carl Love --- patch committed closing -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443180] The subnormal test and the ISA 3.0 test generate compiler warnings.
https://bugs.kde.org/show_bug.cgi?id=443180 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443179] Need new test for the lxvx and stxvx instructions on ISA 2.07 and ISA 3.0 systems
https://bugs.kde.org/show_bug.cgi?id=443179 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443178] Powerpc, test jm-mfspr expected output needs to be updated
https://bugs.kde.org/show_bug.cgi?id=443178 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443035] The copy, paste and cpbort test does not work reliably.
https://bugs.kde.org/show_bug.cgi?id=443035 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443033] Add support for the ISA 3.0 mcrxrx instruction
https://bugs.kde.org/show_bug.cgi?id=443033 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443031] Gcc -many change requires explicit .machine directives
https://bugs.kde.org/show_bug.cgi?id=443031 Carl Love changed: What|Removed |Added Status|RESOLVED|CLOSED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443179] Need new test for the lxvx and stxvx instructions on ISA 2.07 and ISA 3.0 systems
https://bugs.kde.org/show_bug.cgi?id=443179 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Carl Love --- Fix committed. commit 9c22ad00249c1a6739afb2eed1db0a6fb846978c Author: Carl Love Date: Tue Sep 28 18:00:35 2021 + Fixes for the lxvx and stxvx instructions The lxvx and stxvx tests are moved into their own separate tests. Add the expec files for the new test. Update the expected results for the altivec test. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443180] The subnormal test and the ISA 3.0 test generate compiler warnings.
https://bugs.kde.org/show_bug.cgi?id=443180 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Carl Love --- Fix committed. commit bcbfa9e9006aa377a4ed19919af9be6e4ac19267 (HEAD -> master) Author: Carl Love Date: Tue Sep 28 20:58:22 2021 + fix compiler print format warnings in test_isa_3_0.c GCC fixed the compiler warnings long long types. Add explicit casts so gcc will not generate compile warnings. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443178] Powerpc, test jm-mfspr expected output needs to be updated
https://bugs.kde.org/show_bug.cgi?id=443178 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Carl Love --- Committed fix. commit f1d6dec60148d1ca7dc660f98e39ff31a9bfb5a0 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Tue Sep 28 15:49:10 2021 + Fix tests for mfspr Split out the mfspr tests into a separate test using command line option "-M". The value in the LR and CTR registers changed. It appears the changes are due to changes in the test program jm-insns.c. Splinting these instructions out will help to minimize the size of future updates when the test program changes. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443180] New: The subnormal test and the ISA 3.0 test generate compiler warnings.
https://bugs.kde.org/show_bug.cgi?id=443180 Bug ID: 443180 Summary: The subnormal test and the ISA 3.0 test generate compiler warnings. Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- The GCC compiler fixed warning on the long long types. Depending on the version of the gcc compiler used, you may get print warnings for test_subnormal.c and test_isa_3_0.c Need an explicit cast of the print value to eliminate the warnings. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443179] New: Need new test for the lxvx and stxvx instructions on ISA 2.07 and ISA 3.0 systems
https://bugs.kde.org/show_bug.cgi?id=443179 Bug ID: 443179 Summary: Need new test for the lxvx and stxvx instructions on ISA 2.07 and ISA 3.0 systems Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- The lxvx and stxvx instructions are mnemonics of the BE instructions lxvd2x and stxvd2x. They are real endian aware instructions in ISA 3.0. Need a test to generate the lxvd2x and stxv2dx instructions from the lxvx and stxvx mnemonics on ISA 2.07 and the real instructions on ISA 3.0 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443178] New: Powerpc, test jm-mfspr expected output needs to be updated
https://bugs.kde.org/show_bug.cgi?id=443178 Bug ID: 443178 Summary: Powerpc, test jm-mfspr expected output needs to be updated Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: c...@us.ibm.com Target Milestone: --- The jm-insns.c test was changed. It caused the contents of the LR and CTR registers to change. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443034] Sraw, srawi, srad, sradi, mfs
https://bugs.kde.org/show_bug.cgi?id=443034 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443034] Sraw, srawi, srad, sradi, mfs
https://bugs.kde.org/show_bug.cgi?id=443034 --- Comment #1 from Carl Love --- Committed fix for the issue. commit a9f41e0c0b18763a18a1a2abad7981bbd299b235 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Thu Sep 9 23:10:07 2021 + fix sraw, srawi, srad, sradi instructions For ISA 3.0 and beyond, the instructions also write the XER register. Split the instructions out to a new command line option so we can create an ISA 2.07 expect file, ISA 3.0 LE and ISA 3.0 BE expect file. The new command line option is "-s" to just run just these four instructions. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443033] Add support for the ISA 3.0 mcrxrx instruction
https://bugs.kde.org/show_bug.cgi?id=443033 Carl Love changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #1 from Carl Love --- Committed patch to add support for the mxrxrx instruction and the testcase for the instruction. commit a3c3f5394a77c641de19df1b59a7f544e5e0470a (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Wed Sep 29 21:20:30 2021 + New test for the ISA 3.0 mcrxrx instruction. Add new test. commit 7bd75320a0ba995be90e469fe4f26f4a925875b9 Author: Carl Love Date: Thu Sep 9 19:06:00 2021 + Add support for the mcrxrx instruction. The mcrxrx instruction was introduced in ISA 3.0. It was missed when the ISA 3.0 support was added to Valgrind. The mcrxr instruction is not supported on ISA 3.0 and beyond. The instructions both do a move to the condition register however the mcrxrx moves [OV|OV32|CA|CA32]. Where the mcrxr instruction moves XER[32:35] (S0, OV, and CA bits) to the CR. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443031] Gcc -many change requires explicit .machine directives
https://bugs.kde.org/show_bug.cgi?id=443031 Carl Love changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Carl Love --- Patches committed. Changing status to fixed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443035] The copy, paste and cpbort test does not work reliably.
https://bugs.kde.org/show_bug.cgi?id=443035 Carl Love changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443035] The copy, paste and cpbort test does not work reliably.
https://bugs.kde.org/show_bug.cgi?id=443035 --- Comment #3 from Carl Love --- Updated fix has been committed commit a63e9c28b53f20ce1c4bdc0b81da59957a17f4f0 Author: Tulio Magno Quites Machado Filho Date: Fri Aug 20 19:07:09 2021 -0300 powerpc: Add .machine directives for scv, copy, paste, cpabort instructions GCC is no longer passing the "-many" flag to the assembler. So, the inline assembly instructions statements need to use the .machine directives for the specific platform. (gcc commit e154242724b084380e3221df7c08fcdbd8460674 ; "[RS6000] Don't pass -many to the assembler". Hardware sync instruction (hwsync) added after the copy, paste and cpabort instructions to improve the reliability of the test. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 443031] Gcc -many change requires explicit .machine directives
https://bugs.kde.org/show_bug.cgi?id=443031 --- Comment #7 from Carl Love --- commit 7d2cec7f247809f08ce2e93a1a81ce333c6c244b (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Tue Sep 14 19:36:24 2021 + Fixes for mcrxr instruction Add .machine directives to ensure the mcrxr instruction is assembled for power 6. The instruction is not supported on later platforms. commit 518a2d59ac49fd4cd206912d95da76c1631d439c Author: Carl Love Date: Wed Sep 8 22:01:05 2021 + Fix dfp tests. Due to changes between the compiler and linker, we need to add .machine arguments to configure file to properly detect the availability of the dfp instructions. Add print statement if HAS_DFP is not enabled to make it easier to determine when HAS_DFP is not enabled. commit 475916cbd37611dcf510c2249c74ff6e31894023 Author: Carl Love Date: Tue Sep 14 21:43:49 2021 + Add .machine directives for the darn instruction commit e23c2a2291071d1443ff9c6dbce5bbfe2c4cdd7c Author: Carl Love Date: Fri Sep 17 00:33:14 2021 + Fixes to add .machine directives for assembly instructions commit a63e9c28b53f20ce1c4bdc0b81da59957a17f4f0 Author: Tulio Magno Quites Machado Filho Date: Fri Aug 20 19:07:09 2021 -0300 powerpc: Add .machine directives for scv, copy, paste, cpabort instructions GCC is no longer passing the "-many" flag to the assembler. So, the inline assembly instructions statements need to use the .machine directives for the specific platform. (gcc commit e154242724b084380e3221df7c08fcdbd8460674 ; "[RS6000] Don't pass -many to the assembler". Hardware sync instruction (hwsync) added after the copy, paste and cpabort instructions to improve the reliability of the test. commit a9b5f6cfeb0592cb52199cdbe3a36d173b3e32b6 Author: carl love Date: Mon Sep 13 13:02:11 2021 -0500 Configure,makefile and test case fixes for older powerpc targets. Assorted changes to fix up compile issues as seen during regression testing of VG on hardware back as far as Power 6 (ISA 2.05). -- You are receiving this mail because: You are watching all bug changes.
