https://bugs.kde.org/show_bug.cgi?id=417993
Mark Wielaard changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=417993
Eyal changed:
What|Removed |Added
Attachment #162607|0 |1
is obsolete||
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #13 from Eyal ---
> I think my only question is whether we should "clear" all of data or just
> the value fields of the result and opnds[] of the test_data_t?
> I guess it doesn't matter whether the rest of the test_data_t struct values
>
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #12 from Mark Wielaard ---
I think your analysis is correct. We already seem to do this when printing out
a complaint about a real mismatch.
See memcheck/tests/vbits-test/util.c (print_opnd):
/* The value itself might be partially or
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #11 from Eyal ---
Comment on attachment 162608
--> https://bugs.kde.org/attachment.cgi?id=162608
This might fix it, too, but I prefer the other one.
This one is bigger and the other one works just as well so don't use this one.
--
You
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #10 from Eyal ---
Comment on attachment 162608
--> https://bugs.kde.org/attachment.cgi?id=162608
This might fix it, too, but I prefer the other one.
This one is much more convoluted and unnecessary. Just use the other one.
--
You are
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #9 from Eyal ---
Created attachment 162619
--> https://bugs.kde.org/attachment.cgi?id=162619=edit
A test case to force this error even on amd64.
This is just for testing purposes. Don't put this into the repo.
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #8 from Eyal ---
Drawing up the truth table of those two versions of calculating a_min, I find
that only the case when aa is unknown and vaa is 1 make any difference. The
output in the version aa & ~vaa return 0 is aa==x and vaa==1. But
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #7 from Eyal ---
Created attachment 162608
--> https://bugs.kde.org/attachment.cgi?id=162608=edit
This might fix it, too, but I prefer the other one.
We refactor the code so that the computation is done before the vbits are set.
And
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #6 from Eyal ---
Created attachment 162607
--> https://bugs.kde.org/attachment.cgi?id=162607=edit
This might fix the problem and it's the solution that I prefer.
This might fix the problem and it's the solution that I prefer.
After we
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #5 from Eyal ---
Like I said before: As part of the tests, some vbits get set. However, we need
to clear them again before we compute the expectation or else the expectation
*itself* will have vbits set in it. The expectation should have
https://bugs.kde.org/show_bug.cgi?id=417993
Eyal changed:
What|Removed |Added
CC||eyals...@gmail.com
--- Comment #4 from Eyal ---
For
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #3 from Andreas Arnez ---
(In reply to Mark Wielaard from comment #2)
> Since s390x is also big endian maybe this is related to bug #417238 which
> fixes an issue on mips64 BE and ppc64[be]?
Thanks for pointing to this bug; I haven't seen
https://bugs.kde.org/show_bug.cgi?id=417993
Mark Wielaard changed:
What|Removed |Added
See Also||https://bugs.kde.org/show_b
https://bugs.kde.org/show_bug.cgi?id=417993
--- Comment #1 from Andreas Arnez ---
Created attachment 126262
--> https://bugs.kde.org/attachment.cgi?id=126262=edit
Disable And1/Or1 testing in vbit-test
Just for completeness, this is the patch used for disabling the And1/Or1
testing in
15 matches
Mail list logo
