https://bugs.kde.org/show_bug.cgi?id=203380
Julian Seward changed:
What|Removed |Added
Attachment #158504|0 |1
is obsolete
https://bugs.kde.org/show_bug.cgi?id=203380
Julian Seward changed:
What|Removed |Added
Attachment #36062|0 |1
is obsolete
https://bugs.kde.org/show_bug.cgi?id=380942
Julian Seward changed:
What|Removed |Added
Attachment #105965|0 |1
is obsolete
https://bugs.kde.org/show_bug.cgi?id=383010
--- Comment #70 from Julian Seward ---
Created attachment 145020
--> https://bugs.kde.org/attachment.cgi?id=145020&action=edit
Fix handling of no-mask reg-reg versions of VEXPAND* and VCOMPRESS*
Here's a bug fix for the VEXPAND a
https://bugs.kde.org/show_bug.cgi?id=383010
--- Comment #68 from Julian Seward ---
Created attachment 144930
--> https://bugs.kde.org/attachment.cgi?id=144930&action=edit
valgrind-avx512-rollup-fixes-2021Dec29.diff
Rollup fixes to be applied on top of (after) the patches in comments
https://bugs.kde.org/show_bug.cgi?id=383010
--- Comment #67 from Julian Seward ---
Created attachment 144910
--> https://bugs.kde.org/attachment.cgi?id=144910&action=edit
Demonstrates misbehaving `vmovdqu8 %ymm7, (%r9){%k5}`
I've been testing the patches from comment 58, 59, 60
https://bugs.kde.org/show_bug.cgi?id=446103
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=446103
--- Comment #1 from Julian Seward ---
Created attachment 144170
--> https://bugs.kde.org/attachment.cgi?id=144170&action=edit
Proposed patch (needs commit message)
Attached is a proposed fix. It makes gigabyte-sized SARPs about
3 x faste
https://bugs.kde.org/show_bug.cgi?id=446236
--- Comment #2 from Julian Seward ---
Also, if it really is 3.8.1 that you are using .. that is ancient and
unsupported.
Try again with the most recent version, 3.18.1.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=446103
Bug ID: 446103
Summary: Memcheck: `--track-origins=yes` causes extreme
slowdowns for large mmap/munmap
Product: valgrind
Version: unspecified
Platform: Other
OS: L
https://bugs.kde.org/show_bug.cgi?id=445415
Bug ID: 445415
Summary: arm64 front end: alignment checks missing for atomic
instructions
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
https://bugs.kde.org/show_bug.cgi?id=444399
--- Comment #9 from Julian Seward ---
Landed, 530df882b8f60ecacaf2b9b8a719f7ea1c1d1650. I think it's
OK, and the patch contains test cases, but .. please test.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=444399
Julian Seward changed:
What|Removed |Added
Summary|disInstr(arm64): unhandled |disInstr(arm64): unhandled
https://bugs.kde.org/show_bug.cgi?id=444399
Bug 444399 depends on bug 445354, which changed state.
Bug 445354 Summary: arm64 backend: incorrect code emitted for doubleword CAS
https://bugs.kde.org/show_bug.cgi?id=445354
What|Removed |Added
--
https://bugs.kde.org/show_bug.cgi?id=445354
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=444399
Julian Seward changed:
What|Removed |Added
Attachment #143328|0 |1
is obsolete
https://bugs.kde.org/show_bug.cgi?id=445354
Julian Seward changed:
What|Removed |Added
Blocks||444399
Referenced Bugs:
https://bugs.kde.org
https://bugs.kde.org/show_bug.cgi?id=444399
Julian Seward changed:
What|Removed |Added
Depends on||445354
Referenced Bugs:
https://bugs.kde.org
https://bugs.kde.org/show_bug.cgi?id=445354
Bug ID: 445354
Summary: arm64 backend: incorrect code emitted for doubleword
CAS
Product: valgrind
Version: unspecified
Platform: Other
OS: Linux
Statu
https://bugs.kde.org/show_bug.cgi?id=444399
--- Comment #7 from Julian Seward ---
Created attachment 143328
--> https://bugs.kde.org/attachment.cgi?id=143328&action=edit
WIP patch that will possibly get you back on the road. DO NOT LAND.
Fixing this is a whole trip because the various
https://bugs.kde.org/show_bug.cgi?id=434283
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
Resolution
https://bugs.kde.org/show_bug.cgi?id=444399
Julian Seward changed:
What|Removed |Added
CC||a...@ao2.it
--- Comment #6 from Julian Seward
https://bugs.kde.org/show_bug.cgi?id=444399
--- Comment #5 from Julian Seward ---
I looked into this a bit. It does indeed appear that LD{A}XP and ST{L}XP
exist in AArch64 8.0 but are not implemented in V. I am somewhat surprised by
this since I distinctly remember carefully making a list of
https://bugs.kde.org/show_bug.cgi?id=444545
--- Comment #10 from Julian Seward ---
That is all very strange. Q: for the failing case, does
adding `--alignment=32` make any difference? That changes
the alignment produced by `malloc`.
--
You are receiving this mail because:
You are watching
https://bugs.kde.org/show_bug.cgi?id=444545
--- Comment #6 from Julian Seward ---
> Model name:Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
Hmm, nothing particularly exotic there.
> Sorry this is proving more troublesome than I expected.
It's OK; however; we can't fi
https://bugs.kde.org/show_bug.cgi?id=444545
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #4 from Julian
https://bugs.kde.org/show_bug.cgi?id=444399
--- Comment #2 from Julian Seward ---
I can't reproduce this, testing on Fedora 33 on Parallels Workstation
running on an M1 Mac Mini, with either rustc-1.55 or rustc-1.56.
I suspect this is some kind of hardware capabilities problem, in that
https://bugs.kde.org/show_bug.cgi?id=433510
--- Comment #6 from Julian Seward ---
(In reply to Mark Wielaard from comment #5)
> (In reply to Paul Floyd from comment #4)
> > > - TRACE_SYMTAB("rx_map: avma %#lx size %lu foff %ld\n",
> > > + T
https://bugs.kde.org/show_bug.cgi?id=442168
--- Comment #8 from Julian Seward ---
(In reply to Xavier Roche from comment #7)
I checked V's {V,}MOVSD implementation more, and still find no problem
I think this is unrelated to those insns.
If I had to guess, I'd say it *might* be rela
https://bugs.kde.org/show_bug.cgi?id=442168
--- Comment #5 from Julian Seward ---
Looking at the Intel docs for MOVSD and VMOVSD, and comparing against
what guest_amd64_toIR.c implements, I don't see any error in the
implementation. Plus, both of those must be at least moderately commonly
https://bugs.kde.org/show_bug.cgi?id=442168
--- Comment #4 from Julian Seward ---
(In reply to Xavier Roche from comment #2)
> The difference between the correctly executed code under valgrind and the
> faulty one:
> - movsd %xmm0, (%rsp) # 8-b
https://bugs.kde.org/show_bug.cgi?id=432387
--- Comment #5 from Julian Seward ---
(In reply to Andreas Arnez from comment #4)
> > + s390_insn_assert("vcdlg", m3 == 2 || m3 == 3);
> > (multiple times)
> > This will fail only on internal logic errors, correct? .. it
https://bugs.kde.org/show_bug.cgi?id=440893
--- Comment #3 from Julian Seward ---
> It's strange that in my case the data block is always filled with 0's
> (abort() is never called), I'm using gcc 8.5.0 and c++17.
The Linux kernel is obliged to zero out all memory pages i
https://bugs.kde.org/show_bug.cgi?id=432387
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #3 from Julian
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #44 from Julian Seward ---
I meant, unsigned < and <= scalar comparisons on undefined data. Duh.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #43 from Julian Seward ---
As a general note, I have been investigating unsigned < and <=
comparisons on scalar values for arm64, and expect to continue doing
so as a background task for the next few weeks. So, this is not
for
https://bugs.kde.org/show_bug.cgi?id=440095
--- Comment #1 from Julian Seward ---
Try copying the scheme used for 'dc cvau' in guest_arm64_toIR.c.
That might just work for the cases you care about too.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=438630
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #2 from Julian
https://bugs.kde.org/show_bug.cgi?id=438038
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #3 from Julian
https://bugs.kde.org/show_bug.cgi?id=436873
--- Comment #4 from Julian Seward ---
(In reply to ahashmi from comment #3)
> The review fixes for the scalar variants patch
> https://bugs.kde.org/show_bug.cgi?id=436411 (hwcaps-gating and
> iselIntExpr_RIL_wrk issues) means this latest pa
https://bugs.kde.org/show_bug.cgi?id=436411
--- Comment #5 from Julian Seward ---
(In reply to ahashmi from comment #4)
> Created attachment 138947 [details]
> Adds arm64 v8.2 scalar FABD, FACGE, FACGT and FADD instructions
That all looks fine; please land. Just before you do -- if you h
https://bugs.kde.org/show_bug.cgi?id=435665
--- Comment #14 from Julian Seward ---
(In reply to Tulio Magno Quites Machado Filho from comment #13)
> (In reply to Carl Love from comment #12)
> Correct. The address is always mmap'ed.
Ok. Then I think you're good to go as-is
https://bugs.kde.org/show_bug.cgi?id=435665
--- Comment #11 from Julian Seward ---
(In reply to Carl Love from comment #10)
> Created attachment 138846 [details]
> PPC add copy, paste, cpabort support
>
> Updated patch to add the Memcheck trickery to get Memcheck to detect
> un
https://bugs.kde.org/show_bug.cgi?id=435665
--- Comment #9 from Julian Seward ---
So .. I had an idea about how to get the annotations right. Problem is, it's a
nasty hack (although simple), and I had hoped that the passage of a bit of time
would cause me to think of something cleaner.
https://bugs.kde.org/show_bug.cgi?id=436873
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #2 from Julian
https://bugs.kde.org/show_bug.cgi?id=436411
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #3 from Julian
https://bugs.kde.org/show_bug.cgi?id=435665
--- Comment #7 from Julian Seward ---
I looked at the PowerISA 3.0b documentation you linked to.
Given that this is a copy from "normal" memory to an accelerator,
I think you don't have the option to implement it precisely.
I'd sa
https://bugs.kde.org/show_bug.cgi?id=435665
--- Comment #5 from Julian Seward ---
I'm somewhat concerned, at a fundamental level .. if I understand
correctly, these instructions allow one to copy memory from one
place to another (so why bother? Why not just do normal loads/stores?)
but
https://bugs.kde.org/show_bug.cgi?id=434296
--- Comment #8 from Julian Seward ---
(In reply to Andreas Arnez from comment #6)
> OK, done. Unless there's anything else, I'm going to push with this change
> then.
Yes, pls land. Looks fine to me.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=434296
--- Comment #5 from Julian Seward ---
(In reply to Andreas Arnez from comment #4)
> > 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
> th
https://bugs.kde.org/show_bug.cgi?id=431157
--- Comment #29 from Julian Seward ---
(In reply to Carl Love from comment #27)
> Created attachment 137063 [details]
> patch to add support for the scv instruction
This looks OK to me.
> One issue with the patch is the SC_FLAG and SCV_FLA
https://bugs.kde.org/show_bug.cgi?id=434840
--- Comment #7 from Julian Seward ---
(In reply to Carl Love from comment #6)
> Created attachment 137204 [details]
> patch to add darn instruction support
+static Int dis_darn ( UInt prefix, UInt theInstr,
+
+ IRExpr** args = mkIRExprVec_1(
https://bugs.kde.org/show_bug.cgi?id=435665
--- Comment #2 from Julian Seward ---
(In reply to Carl Love from comment #1)
> Created attachment 137535 [details]
> PPC add copy, paste, cpabort support
+ d = unsafeIRDirty_1_N (
+ cr0,
+ 0/*re
https://bugs.kde.org/show_bug.cgi?id=434296
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #3 from Julian
https://bugs.kde.org/show_bug.cgi?id=433863
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #4 from Julian
https://bugs.kde.org/show_bug.cgi?id=433801
--- Comment #8 from Julian Seward ---
(In reply to Carl Love from comment #4)
> Created attachment 136294 [details]
> functional tests for Reduced-Precision: Missing Integer-based Outer
> Product Operations
OK to land. Again, please ensur
https://bugs.kde.org/show_bug.cgi?id=433801
--- Comment #7 from Julian Seward ---
(In reply to Carl Love from comment #2)
> Created attachment 136292 [details]
> functional tests for Reduced-Precision - bfloat16 Outer Product & Format
> Conversion Operations
OK to land. Ple
https://bugs.kde.org/show_bug.cgi?id=433801
--- Comment #6 from Julian Seward ---
(In reply to Carl Love from comment #3)
> Created attachment 136293 [details]
> PPC64: Reduced-Precision: Missing Integer-based Outer Product Operations
-static UInt exts8( UInt src)
+static ULong exts8
https://bugs.kde.org/show_bug.cgi?id=433801
--- Comment #5 from Julian Seward ---
(In reply to Carl Love from comment #1)
> Created attachment 136291 [details]
> Reduced-Precision - bfloat16 Outer Product & Format Conversion Operations
+static Float conv_bf16_to_float(
https://bugs.kde.org/show_bug.cgi?id=429375
--- Comment #5 from Julian Seward ---
Looks OK to land now.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=434840
--- Comment #5 from Julian Seward ---
(In reply to Carl Love from comment #4)
> Created attachment 136999 [details]
> patch to add darn instruction support
+ULong darn_dirty_helper ( UInt L )
+{
+
...
+# else
+ val = 0xULL; /*
https://bugs.kde.org/show_bug.cgi?id=434840
--- Comment #2 from Julian Seward ---
(In reply to Carl Love from comment #1)
Handing it off to the hardware via a helper function is the right
thing to do. But you can't use a clean helper for this; that breaks
the rules for clean helpers. A
https://bugs.kde.org/show_bug.cgi?id=401416
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|CONFIRMED
https://bugs.kde.org/show_bug.cgi?id=401416
--- Comment #5 from Julian Seward ---
(In reply to Mark Wielaard from comment #4)
> Is there a reason to remove them completely instead of keep using the if
> defined (...) constructs?
I had wondered that too. I'm trying the if-def
https://bugs.kde.org/show_bug.cgi?id=434193
Julian Seward changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #22 from Julian Seward ---
(In reply to Eyal from comment #21)
> Will anyone consider the patch?
This (problem) is definitely something I want to deal with, and your
patch seems like a good starting place. However, 3.17 is imminent an
https://bugs.kde.org/show_bug.cgi?id=434193
--- Comment #6 from Julian Seward ---
Here's my proposed fix. It works for your test case on x86_64
but I didn't test it on arm64. Does it work for you?
diff --git a/memcheck/mc_translate.c b/memcheck/mc_translate.c
index 516988bdd..759f00
https://bugs.kde.org/show_bug.cgi?id=434193
--- Comment #5 from Julian Seward ---
(In reply to Mike Crowe from comment #4)
> It ain't half slow on anything more than toy test cases though. :)
That was a general test to establish whether lack of precise
instrumentation was indeed the
https://bugs.kde.org/show_bug.cgi?id=434193
--- Comment #3 from Julian Seward ---
Does running with --expensive-definedness-checks=yes make any difference?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=430429
--- Comment #6 from Julian Seward ---
(In reply to Paul Floyd from comment #5)
> Quick confirmation for amd64 Fedora. No problems with clang 11 or clang 13
Thanks.
(general comment, not suggesting any action right now): Looking at valgrind.h
now
https://bugs.kde.org/show_bug.cgi?id=431157
--- Comment #25 from Julian Seward ---
(In reply to Tom Hughes from comment #24)
> Indeed if that is -2 that would be errno 2 aka ENOENT which would make sense.
Agreed.
So then it would seem to me that the problem is that the patch doesn'
https://bugs.kde.org/show_bug.cgi?id=431157
--- Comment #23 from Julian Seward ---
(In reply to Tom Hughes from comment #22)
> So if thinks the open was a success with a negative file descriptor returned?
Ah, maybe it's trying to tell us something :-) I vaguely remember reading
that
https://bugs.kde.org/show_bug.cgi?id=430429
--- Comment #4 from Julian Seward ---
(In reply to Andreas Arnez from comment #2)
@Andreas: if the patch works on s390, I think you should land it.
> @Julian: Isn't the patch necessary for other 64-bit platforms as well then?
> Such as
https://bugs.kde.org/show_bug.cgi?id=431157
--- Comment #20 from Julian Seward ---
Looking at the end of the log there:
SYSCALL[279836,1](291) sys_newfstatat ( 24, 0x4a73980(), 0x4ad2578 )[sync] -->
Failure(0x9)
SYSCALL[279836,1](90) sys_mmap ( 0x0, 0, 1, 2, 24, 0 ) --> [pre-fail]
Failur
https://bugs.kde.org/show_bug.cgi?id=432552
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=432552
Julian Seward changed:
What|Removed |Added
Summary|[AArch64] invalid error |[AArch64] invalid error
https://bugs.kde.org/show_bug.cgi?id=429354
--- Comment #6 from Julian Seward ---
Thanks for the fixes. r+; please land.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=432552
--- Comment #1 from Julian Seward ---
I suspect this can be fixed by finding the following at or near
line 4967 of guest_arm64_toIR.c
Bool earlyWBack
= wBack && simm9 < 0 && (szB == 8 || szB == 4)
https://bugs.kde.org/show_bug.cgi?id=432801
--- Comment #17 from Julian Seward ---
Interesting analysis, and a plausible patch; thank you for that. This seems
like a new trick from LLVM.
I'm still struggling to understand what's going on, though. I can see that
for (size_t i = 0
https://bugs.kde.org/show_bug.cgi?id=429354
--- Comment #4 from Julian Seward ---
return a & 0xFF, I meant.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=429354
--- Comment #3 from Julian Seward ---
(In reply to Julian Seward from comment #2)
>uint16_t getMSBs_8x16(vec128)
>{
> let hiHalf = vec128[127:64] // LE numbering
> let loHalf = vec128[ 63:0]
> // In each byte
https://bugs.kde.org/show_bug.cgi?id=429375
--- Comment #3 from Julian Seward ---
==
https://bugs.kde.org/attachment.cgi?id=133479
test cases for VSX-PCV generate operations
OK to land
==
https://bugs.kde.org/attachment.cgi?id=134757
VSX- PCV Generate
https://bugs.kde.org/show_bug.cgi?id=429354
--- Comment #2 from Julian Seward ---
==
https://bugs.kde.org/attachment.cgi?id=133462
Test cases for VSX Mask Manipulation operations
OK to land
==
https://bugs.kde.org/attachment.cgi?id=133461
Functional support
https://bugs.kde.org/show_bug.cgi?id=429352
--- Comment #10 from Julian Seward ---
==
https://bugs.kde.org/attachment.cgi?id=133459
Test cases for new IOps
OK to land
==
https://bugs.kde.org/attachment.cgi?id=135083
Fix pcast for existing code
OK to land
https://bugs.kde.org/show_bug.cgi?id=432510
--- Comment #2 from Julian Seward ---
(In reply to Frank Ch. Eigler from comment #0)
Before we get into discussing how to implement stuff, I think it's important to
have a more precise statement of what functionality is required. Can you give
https://bugs.kde.org/show_bug.cgi?id=432161
--- Comment #6 from Julian Seward ---
(In reply to ahashmi from comment #5)
Looks good to me. Land!
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=432161
--- Comment #3 from Julian Seward ---
Nicely done! I did spot one bug though:
@@ -3752,6 +3775,8 @@ IRAtom* expr2vbits_Binop ( MCEnv* mce,
case Iop_I32StoF32x4:
case Iop_F32toI32Sx4:
+ case Iop_Sqrt16Fx8:
+ return
https://bugs.kde.org/show_bug.cgi?id=429352
--- Comment #5 from Julian Seward ---
(In reply to Carl Love from comment #1)
> Created attachment 133459 [details]
> Test cases for new IOps
>
> The test cases
This seems OK to be. But per comments on
https://bugs.kde.org/attachment.c
https://bugs.kde.org/show_bug.cgi?id=429352
--- Comment #4 from Julian Seward ---
(In reply to Carl Love from comment #0)
> Created attachment 133458 [details]
> Functional support for ISA 3.1, New Iops
>
> Power PC missing ISA 3.1 support. Additional patches, part 7
It seems to
https://bugs.kde.org/show_bug.cgi?id=431556
Julian Seward changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=431556
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #3 from Julian
https://bugs.kde.org/show_bug.cgi?id=413547
Julian Seward changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=414268
Julian Seward changed:
What|Removed |Added
Status|CONFIRMED |RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=413547
--- Comment #7 from Julian Seward ---
You can get to an "patch is obsolete" check box by following the twisty
maze attached to the "Details" link on the "Attachments" box.
Anyways, review comments.
This looks f
https://bugs.kde.org/show_bug.cgi?id=413547
Julian Seward changed:
What|Removed |Added
Attachment #133667|0 |1
is obsolete
https://bugs.kde.org/show_bug.cgi?id=413547
--- Comment #5 from Julian Seward ---
Assad, am I right to understand that the comment 3 patch
has been made redundant by the comment 4 patch?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=414268
--- Comment #14 from Julian Seward ---
Thank you all for the high quality discussion and analysis. This looks
fine to me; please land.
One tiny nit .. please #undef get_cpu_ftr and get_ftr just before the
closing brace of the fn that defines them.
I
https://bugs.kde.org/show_bug.cgi?id=429864
--- Comment #1 from Julian Seward ---
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.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=428716
Julian Seward changed:
What|Removed |Added
CC||jsew...@acm.org
--- Comment #6 from Julian
https://bugs.kde.org/show_bug.cgi?id=427404
--- Comment #11 from Julian Seward ---
OK to land provided that setup_fxstate_struct Read/Write/Modify annotations are
set more precisely, so as to avoid false positives and false negatives from
Memcheck.
--
You are receiving this mail because:
You
1 - 100 of 900 matches
Mail list logo
