https://bugs.kde.org/show_bug.cgi?id=386945
--- Comment #63 from Mark Wielaard <m...@klomp.org> ---
(In reply to Julian Seward from comment #62)
> Created attachment 116827 [details]
> Possible fix for the comment 61 problems
>
> This patch:
>
> * changes set_AV_CR6 so that it does scalar comparisons against zero,
> rather than sometimes against an all-ones word. This is something
> that Memcheck can instrument exactly.
>
> * in Memcheck, requests expensive instrumentation of Iop_Cmp{EQ,NE}64
> by default on ppc64le.
>
> Note, this is all untested! In particular it would be good to verify
> that the CR6 results are unchanged.
That definitely fixes the issue. I tested on both power9 and power8 with a gcc
and glibc build with the new str[n]cmp inline patch plus the following fixes
from this bug:
- Implement ppc64 ldbrx as 64-bit load and Iop_Reverse8sIn64_x1.
- memcheck: Allow unaligned loads of words on ppc64[le].
- Implement ppc64 lxvd2x as 128-bit load with double word swap for ppc64le.
- memcheck: Allow unaligned loads of 128bit vectors on ppc64[le].
- Implement ppc64 lxvb16x as 128-bit vector load with reversed double words.
And it seems to resolve all gcc strcmp inline issues I was seeing before.
Both setups were ppc64le. I haven't yet tested on ppc64 or ppc32.
I do see bug #401827 and bug #401828 but they are unrelated.
Also memcheck/tests/undef_malloc_args (stderr) fails. That one does seem caused
by earlier patches from this bug.
And occasionally I see Use of uninitialised value of size 8 in _vgnU_freeres
(vg_preloaded.c:68) which is mysterious. It goes away with
--run-libc-freeres=no --run-cxx-freeres=no. It seems unrelated to this issue.
But I haven't found out yet what is causing it. It is as if sometimes we are
unable to see that the weak symbol _ZN9__gnu_cxx9__freeresEv
(__gnu_cxx::__freeres) is initialized. Very odd, since it normally works except
in some cases. But it is very likely unrelated to this bug.
--
You are receiving this mail because:
You are watching all bug changes.
