https://bugs.kde.org/show_bug.cgi?id=385409
Andreas Arnez changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #77 from Andreas Arnez ---
Regarding the question whether the disassembler works for the new insns,
I've experimented a bit with --trace-flags=1000. It turned out that
the vector_integer test case crashed with this option, because when
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #76 from Julian Seward ---
(In reply to Andreas Arnez from comment #75)
> (In reply to Julian Seward from comment #74)
> > Looks fine to me. Just two minor nits:
Ok, no problem; I don't have a strong preference for my suggestions.
Leave it
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #75 from Andreas Arnez ---
(In reply to Julian Seward from comment #74)
> Looks fine to me. Just two minor nits:
>
> --- a/VEX/priv/host_s390_isel.c
> +++ b/VEX/priv/host_s390_isel.c
>
> - UInt vec_op = 0;
> + s390_unop_t vec_op
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #74 from Julian Seward ---
(In reply to Andreas Arnez from comment #73)
> Created attachment 115231 [details]
> Fixes based on Julian's comment #71
>
> For reference, here's what I changed based on the comments above. I'll look
> more into
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #73 from Andreas Arnez ---
Created attachment 115231
--> https://bugs.kde.org/attachment.cgi?id=115231&action=edit
Fixes based on Julian's comment #71
For reference, here's what I changed based on the comments above. I'll look
more into
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #72 from Andreas Arnez ---
(In reply to Julian Seward from comment #71)
> Thank you for finishing this up. OK to land provided the stuff below
> is fixed (none of it is a big deal) and the test in the next para
> passes.
Thanks for reviewin
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #71 from Julian Seward ---
(In reply to Andreas Arnez from comment #68)
> Created attachment 115209 [details]
> s390x: Vector integer and string instruction support
Thank you for finishing this up. OK to land provided the stuff below is fi
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #70 from Julian Seward ---
(In reply to Andreas Arnez from comment #69)
> Created attachment 115210 [details]
> s390x: Vector string and insn support -- tests
This is fine. OK to land.
--
You are receiving this mail because:
You are watc
https://bugs.kde.org/show_bug.cgi?id=385409
Andreas Arnez changed:
What|Removed |Added
Attachment #114206|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
Andreas Arnez changed:
What|Removed |Added
Attachment #114207|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #67 from Vadim Barkov ---
(In reply to Andreas Arnez from comment #66)
> (In reply to Mark Wielaard from comment #65)
> > The answer to that is (it is actually 8 patches) and they should all be
> > applied in order.
> Correct.
> > Should som
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #66 from Andreas Arnez ---
(In reply to Mark Wielaard from comment #65)
> The answer to that is (it is actually 8 patches) and they should all be
> applied in order.
Correct.
> Should some of them be combined before being committed to
> git?
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #65 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #64)
> Which attached patches (there are 7 now) and in which order should they be
> applied?
The answer to that is (it is actually 8 patches) and they should all be applied
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #64 from Mark Wielaard ---
Which attached patches (there are 7 now) and in which order should they be
applied?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #63 from Andreas Arnez ---
(In reply to Julian Seward from comment #62)
> Yes. Good. That looks fine to me. Thank you for redoing it.
Great! Can the patches attached to this Bugzilla go upstream then?
--
You are receiving this mail bec
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #62 from Julian Seward ---
(In reply to Andreas Arnez from comment #60)
> Created attachment 114958 [details]
> Implement VLL/VLBB with aligned loads
Yes. Good. That looks fine to me. Thank you for redoing it.
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #61 from Andreas Arnez ---
Is this OK now?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=385409
Andreas Arnez changed:
What|Removed |Added
Attachment #114932|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #59 from Andreas Arnez ---
(In reply to Julian Seward from comment #58)
> * you use a construction "mkexpr(mktemp(type, expr))" which I am not
> sure what the purpose is. For expressions that will get used more
> than once, you should b
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #58 from Julian Seward ---
(In reply to Andreas Arnez from comment #57)
> Created attachment 114932 [details]
> Implement VLL with aligned loads
> Subject: [PATCH] s390x: Implement VLL/VLBB with aligned loads
Looks ok to me. OK to land wi
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #57 from Andreas Arnez ---
Created attachment 114932
--> https://bugs.kde.org/attachment.cgi?id=114932&action=edit
Implement VLL with aligned loads
This fixes complaints from memcheck in cases where VLL is used for strlen,
strcpy, etc. T
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #56 from Andreas Arnez ---
(In reply to Julian Seward from comment #54)
> [...]
> Memcheck's "partial-loads-OK" heuristic, which is now enabled by default,
> should remove these complaints. So the question is, why isn't it? See
> mc_LOADV_
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #55 from Vadim Barkov ---
(In reply to Julian Seward from comment #47)
> (In reply to Vadim Barkov from comment #46)
> > Since the issue is solved,
>
> I don't consider it to be solved.
>
> You didn't answer my questions in comment 44:
>
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #54 from Julian Seward ---
(In reply to Andreas Arnez from comment #50)
> In the meantime I noticed that we have another fundamental problem that
> comes with GCC's inlined strlen: The last vector load (VL, or with length =
> VLL) may read
https://bugs.kde.org/show_bug.cgi?id=385409
Vadim Barkov changed:
What|Removed |Added
Attachment #114484|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #52 from Vadim Barkov ---
Created attachment 114484
--> https://bugs.kde.org/attachment.cgi?id=114484&action=edit
Refactoring
Refactoring
Simplified code for most of vector integer instructions (and some vector basic
ones). Mostly I've r
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #51 from Andreas Arnez ---
Created attachment 114453
--> https://bugs.kde.org/attachment.cgi?id=114453&action=edit
Fix vector register move insns
This fixes the internal error I've mentioned in comment #50.
--
You are receiving this mai
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #50 from Andreas Arnez ---
Vadim, thanks for the reworks of VLL and VFENE. These help quite considerably,
and the false positives we've seen before are gone. Now I'm debugging an
internal error that seems related to the z13 patches, but no
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #49 from Vadim Barkov ---
(In reply to Florian Weimer from comment #48)
> With the current set of patches, I still see failures for the following
> glibc string function tests:
>
> string/test-memcmp
> string/test-strcasecmp
> string/test-s
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #48 from Florian Weimer ---
With the current set of patches, I still see failures for the following glibc
string function tests:
string/test-memcmp
string/test-strcasecmp
string/test-strcmp
string/test-strncasecmp
string/test-strncmp
You c
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #47 from Julian Seward ---
(In reply to Vadim Barkov from comment #46)
> Since the issue is solved,
I don't consider it to be solved.
You didn't answer my questions in comment 44:
* what your implementation strategy is
* about the relati
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #46 from Vadim Barkov ---
Since the issue is solved, is it ready to merge? Or additional testing is
needed?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #45 from Vadim Barkov ---
(In reply to Julian Seward from comment #44)
The new VFENE implementation has no problems. I just want to point you that in
my opinion the memchecks' "Conditional jump or move depends on uninitialised
value(s)" err
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #44 from Julian Seward ---
(In reply to Vadim Barkov from comment #43)
> What do you think about it?
Honestly, I do not understand. You need to explain much more clearly:
* what these instructions actually do
* what your implementation
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #43 from Vadim Barkov ---
Generally speaking I think that warning in inline strlen is correct because the
VFENE specification says:
If ZS (zero search) flag is set, then each element in the second operand is
compared for equality with zero.
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #42 from Vadim Barkov ---
Good news! I've solved the strlen inlining issue.
The old VFENE implementation used the dirty helper, which marked second and
third argument fully read (16 bytes). This is semantically wrong because this
instructio
https://bugs.kde.org/show_bug.cgi?id=385409
Vadim Barkov changed:
What|Removed |Added
Attachment #114334|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
Mark Wielaard changed:
What|Removed |Added
CC||m...@klomp.org
--- Comment #40 from Mark Wielaa
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #39 from Florian Weimer ---
(In reply to Vadim Barkov from comment #38)
> (In reply to Florian Weimer from comment #30)
>
> Floarian,
>
> I can't reproduce the problem that you describe. Could you take my patch
> (attachment 114327 [detail
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #38 from Vadim Barkov ---
(In reply to Florian Weimer from comment #30)
Floarian,
I can't reproduce the problem that you describe. Could you take my patch
(attachment 114327) and test against your executable?
--
You are receiving this ma
https://bugs.kde.org/show_bug.cgi?id=385409
Vadim Barkov changed:
What|Removed |Added
Attachment #114305|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #36 from Julian Seward ---
(In reply to Vadim Barkov from comment #35)
> (In reply to Florian Weimer from comment #30)
>
> Are you sure that VLL is the reason of the bug with strlen?
Exactly which bug are you referring to? If you mean th
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #35 from Vadim Barkov ---
(In reply to Florian Weimer from comment #30)
Are you sure that VLL is the reason of the bug with strlen? If so, I believe
that the conditional load implementation is the most natural. I'll add support
for conditio
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #34 from Vadim Barkov ---
(In reply to Julian Seward from comment #32)
> What does VFENEZBS do?
VFENE V1, V2, V3 -- vector find element not equal
It elementwise compares V2 and V3. If an unequal element is found, its index is
stored in byt
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #33 from Julian Seward ---
(In reply to Andreas Arnez from comment #23)
> Julian, is this OK now?
Considering comment 30, alas, no. Let's try and get the Memcheck problems
with this fixed first.
--
You are receiving this mail because:
Yo
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #32 from Julian Seward ---
(In reply to Florian Weimer from comment #30)
> Created attachment 114305 [details]
> Implement early exit in s390_vr_loadWithLength
>
> Updated patch. This seems to fix the VLL issue. Limited testing only.
It
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #31 from Julian Seward ---
(In reply to Florian Weimer from comment #29)
> Created attachment 114302 [details]
> Use guarded loads in the guest
>
> This patch changes the guest code to use guarded loads.
>
> However, this insufficient beca
https://bugs.kde.org/show_bug.cgi?id=385409
Florian Weimer changed:
What|Removed |Added
Attachment #114302|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #29 from Florian Weimer ---
Created attachment 114302
--> https://bugs.kde.org/attachment.cgi?id=114302&action=edit
Use guarded loads in the guest
This patch changes the guest code to use guarded loads.
However, this insufficient because
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #28 from Florian Weimer ---
Found it:
/* A ternary if-then-else operator. It returns iftrue if cond is
nonzero, iffalse otherwise. Note that it is STRICT, ie. both
iftrue and iffalse are evaluate
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #27 from Florian Weimer ---
Hopefully someone can see what is wrong with the generated IR:
vll %v0,%r4,0(%r2)
-- IMark(0x401892E, 6, 0) --
t6 = Add64(0x0:I64,GET:I64(592))
t7 = GET:I32(
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #26 from Florian Weimer ---
The SIGSEGV happens here in the generated code:
(gdb) disas 0x0010038c9230,+20
Dump of assembler code from 0x10038c9230 to 0x10038c9244:
0x0010038c9230: l
https://bugs.kde.org/show_bug.cgi?id=385409
Florian Weimer changed:
What|Removed |Added
CC||fwei...@redhat.com
--- Comment #25 from Floria
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #24 from Andreas Arnez ---
In the meantime I did some more testing, and one thing I found is that VFENE
also marks bytes in the input vectors beyond the zero-terminator as read. This
leads to lots of false positives with real workloads. Th
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #23 from Andreas Arnez ---
Julian, is this OK now?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #22 from Andreas Arnez ---
Created attachment 114230
--> https://bugs.kde.org/attachment.cgi?id=114230&action=edit
Fix strict aliasing violation
This fix applies to Vadim's new version. It also undoes the change from
UChar[6] to ULong, b
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #21 from Andreas Arnez ---
(In reply to Julian Seward from comment #20)
> To tell the truth, we have built with -fno-strict-aliasing for about a
> decade now :-/ But I still would prefer not to have such casting.
Hm, for guest_s390_helpers.
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #20 from Julian Seward ---
(In reply to Ivo Raisr from comment #19)
> (In reply to Andreas Arnez from comment #18)
>
> > Another suspicous construct is the type cast
> > (const s390x_vec_op_details_t*) &details
> > where 'details' is a UL
https://bugs.kde.org/show_bug.cgi?id=385409
Ivo Raisr changed:
What|Removed |Added
CC||iv...@ivosh.net
--- Comment #19 from Ivo Raisr ---
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #18 from Andreas Arnez ---
(In reply to Julian Seward from comment #14)
> More likely is that there's some violation of C "defined behaviour"
> that the compiler is exploiting whilst optimising. Or some type
> error. I would prefer that yo
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #17 from Vadim Barkov ---
(In reply to Julian Seward from comment #14)
Okay, I've refixed that issue without volatile (replaced UChar[6] array with
ULong in union).
Please, check the final version out. It includes the Andreas' patch and so
https://bugs.kde.org/show_bug.cgi?id=385409
Vadim Barkov changed:
What|Removed |Added
Attachment #114122|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
Vadim Barkov changed:
What|Removed |Added
Attachment #114145|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #14 from Julian Seward ---
(In reply to Vadim Barkov from comment #13)
> I've made the union in s390x_dirtyhelper_vec_op volatile and the bug
> magically dissapeared.
>
> Fixed.
No. Just hidden.
More likely is that there's some violation
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #13 from Vadim Barkov ---
I've made the union in s390x_dirtyhelper_vec_op volatile and the bug magically
dissapeared.
Fixed.
Now I'll rearrange all stuff into two patches (tests & code) and submit here.
--
You are receiving this mail bec
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #12 from Vadim Barkov ---
Andreas, I've reproduced the bug.
This occurs only when compiling valgrind with gcc-8 (I've used "gcc (SUSE
Linux) 8.1.1 20180719") and with default optimisation flags (I guess it is
"-O2").
I've compiled with same
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #11 from Julian Seward ---
Vadim, Andreas, please can you split this into two patches:
* one with all the tests
* one with the final bug-fixed implementation
so it's easier to review.
--
You are receiving this mail because:
You are watchin
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #10 from Andreas Arnez ---
Created attachment 114152
--> https://bugs.kde.org/attachment.cgi?id=114152&action=edit
Fix vector register number calculation
Independent from the vtm issue above, I noticed another problem with the
current vec
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #9 from Andreas Arnez ---
Created attachment 114150
--> https://bugs.kde.org/attachment.cgi?id=114150&action=edit
Test case diff with vtm failure
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #8 from Andreas Arnez ---
(In reply to Vadim Barkov from comment #7)
> Andreas,
>
> I can't reproduce you test results so I added tests for every possible
> result of VTM instruction. Could you apply patch from attachment 114145
> [details]
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #7 from Vadim Barkov ---
Andreas,
I can't reproduce you test results so I added tests for every possible result
of VTM instruction. Could you apply patch from attachment 114145 and write the
results to me?
I need more information to reprod
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #6 from Vadim Barkov ---
Created attachment 114145
--> https://bugs.kde.org/attachment.cgi?id=114145&action=edit
More tests for VTM instruction
Changes:
Added tests for all possible result of VTM instruction.
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #5 from Andreas Arnez ---
(In reply to Vadim Barkov from comment #4)
> Now this patch can be applied on master (on
> d44563c49e55f47016e23591f708c7aa57f7a098 or later commit)
Good! Tried the patch, and it looks good, with one exception: th
https://bugs.kde.org/show_bug.cgi?id=385409
Vadim Barkov changed:
What|Removed |Added
Attachment #110339|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=385409
--- Comment #3 from Vadim Barkov ---
(In reply to Christian Borntraeger from comment #2)
> I have not checked if these patches still apply, but for the general patches
> consider these patches acked from my s390x perspective.
I've ensured that this pat
https://bugs.kde.org/show_bug.cgi?id=385409
Christian Borntraeger changed:
What|Removed |Added
CC||borntrae...@de.ibm.com
--- Comment #2 f
https://bugs.kde.org/show_bug.cgi?id=385409
Vadim Barkov changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=385409
Vadim Barkov changed:
What|Removed |Added
CC||vbr...@gmail.com
--- Comment #1 from Vadim Barko
https://bugs.kde.org/show_bug.cgi?id=385409
Andreas Arnez changed:
What|Removed |Added
Blocks|366413 |
Referenced Bugs:
https://bugs.kde.org/show_b
https://bugs.kde.org/show_bug.cgi?id=385409
Andreas Arnez changed:
What|Removed |Added
Blocks||366413
Referenced Bugs:
https://bugs.kde.org/
81 matches
Mail list logo
