https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #32 from Tom Hughes ---
No version of gcc is going to enable AVX512 by default though I think you may
be able to specify a different default target when compiling gcc.
Usually this sort of problem is caused by using -march=native which
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #30 from Tom Hughes ---
The short version however is that valgrind doesn't support AVX512 yet so don't
compile your code for AVX512 if you want to be able to use valgrind on it, and
that includes any libraries you use.
Note that valgrind
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #29 from Tom Hughes ---
So the four byte EVEX prefix of 62 f1 fe 08 decodes as:
EVEX.mm = 0b01 / 1
EVEX.pp = 0b10 / 2
EVEX.RXB = 0b111 / 7
EVEX.R’ = 0b1/ 1
EVEX.X= 0b1/ 1
EVEX. = 0b / 15
EVEX.V’ = 0b1
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #28 from Tom Hughes ---
So 0x62 is an EVEX prefix, but the opcode map fails to mention that even in the
October 2019 edition of the Intel manual...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #27 from Tom Hughes ---
So there really are instructions starting with 0x62 it seems... Some examples:
5ca6f: 62 f1 fe 08 6f 45 00vmovdqu64 0x0(%rbp),%xmm0
90bf6: 62 e1 7c 08 11 56 0avmovups %xmm18,0xa0(%rsi
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #22 from Tom Hughes ---
I was afraid that might happen as it's a local function that isn't exported...
Are you able to just gzip the output it and attach it here?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #19 from Tom Hughes ---
In fact you should be able to just disassemble that function with:
objdump --disassemble=H5P_dup_prop /usr/lib64/libhdf5.so.103.1.0
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #17 from Tom Hughes ---
It's /usr/lib64/libhdf5.so.103.1.0 you need to run objdump on, not your
application, as that library is where the problem instruction is found.
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=415382
--- Comment #4 from Tom Hughes ---
*** This bug has been marked as a duplicate of bug 356715 ***
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=356715
--- Comment #5 from Tom Hughes ---
This is VCVTPH2PS and is fixed in the 3.15.0 release.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=398870
Tom Hughes changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=356715
Tom Hughes changed:
What|Removed |Added
CC||the.true.nathan.mills@gmail
https://bugs.kde.org/show_bug.cgi?id=398870
Tom Hughes changed:
What|Removed |Added
CC||the.true.nathan.mills@gmail
https://bugs.kde.org/show_bug.cgi?id=415382
Tom Hughes changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=415382
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #2 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=415159
--- Comment #3 from Tom Hughes ---
Well yes they will all spin off children because rustc is a separate program to
cargo - it's like tracing make and it not following over the exec when it runs
gcc to do the actual compile.
Note that --trace-children
https://bugs.kde.org/show_bug.cgi?id=415159
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #12 from Tom Hughes ---
Can you please try and disassemble the problem function - this should do it I
think:
objdump --disassemble=_ZN7rocksdb27AdvancedColumnFamilyOptionsC2Ev
/root/open_source/rocksdb/build/librocksdb.so.6.6.0
Then post
https://bugs.kde.org/show_bug.cgi?id=414944
--- Comment #3 from Tom Hughes ---
Right but 0x62 is a single byte instruction so only the first byte matters...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393351
Tom Hughes changed:
What|Removed |Added
CC||caiyueq...@bytedance.com
--- Comment #9 from Tom
https://bugs.kde.org/show_bug.cgi?id=393351
Tom Hughes changed:
What|Removed |Added
CC||jody@gmail.com
--- Comment #8 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=414053
Tom Hughes changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=414944
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=414870
--- Comment #3 from Tom Hughes ---
Well sure gcc may have generated different code.
The point is that once you use long double on x86-32 there is no guarantee you
will get the same results under valgrind as when running natively. You might,
but you
https://bugs.kde.org/show_bug.cgi?id=414870
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=400538
Tom Hughes changed:
What|Removed |Added
CC||eekn...@gmail.com
--- Comment #13 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=414659
--- Comment #10 from Tom Hughes ---
Ah I had a feeling it has been fixed recently but I missed that.
The user here is running 3.13 so won't have the fix but I'll update the
duplicate.
*** This bug has been marked as a duplicate of bug 400538
https://bugs.kde.org/show_bug.cgi?id=253657
Tom Hughes changed:
What|Removed |Added
CC||eekn...@gmail.com
--- Comment #26 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=414659
Tom Hughes changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=414659
Tom Hughes changed:
What|Removed |Added
Summary|Unrecognised instruction|vex amd64->IR: unhandled
|/
https://bugs.kde.org/show_bug.cgi?id=414659
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #4 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=414291
Tom Hughes changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=414291
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=414053
Tom Hughes changed:
What|Removed |Added
Summary|vex amd64->IR: unhandled|vex amd64->IR: unh
https://bugs.kde.org/show_bug.cgi?id=393351
--- Comment #7 from Tom Hughes ---
Sorry I mean on https://bugs.kde.org/show_bug.cgi?id=40...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=393351
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #6 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=393351
Tom Hughes changed:
What|Removed |Added
CC||andrei...@gmail.com
--- Comment #5 from Tom
https://bugs.kde.org/show_bug.cgi?id=40
Tom Hughes changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=393351
Tom Hughes changed:
What|Removed |Added
CC||wang8...@umn.edu
--- Comment #4 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=394582
Tom Hughes changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=411303
Tom Hughes changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=393351
Tom Hughes changed:
What|Removed |Added
CC||wmzhao.c...@gmail.com
--- Comment #3 from Tom
https://bugs.kde.org/show_bug.cgi?id=411303
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Summary|Illegal
https://bugs.kde.org/show_bug.cgi?id=410764
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=410562
Tom Hughes changed:
What|Removed |Added
Status|RESOLVED|REPORTED
Resolution|DUPLICATE
https://bugs.kde.org/show_bug.cgi?id=398086
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #7 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=191062
Tom Hughes changed:
What|Removed |Added
CC||memec...@gmail.com
--- Comment #4 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=410562
Tom Hughes changed:
What|Removed |Added
Status|REPORTED|RESOLVED
CC
https://bugs.kde.org/show_bug.cgi?id=356715
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #4 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=40
--- Comment #2 from Tom Hughes ---
The latest (May 2019) edition seems to agree.
Did you compile this yourself, and if you did what architecture did you target
exactly?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=40
--- Comment #1 from Tom Hughes ---
In 32 bit mode 0x62 would be BOUND which would win some sort of obscurity
contest, but in 64 bit mode it doesn't appear to be valid and as far as I can
see it hasn't been replaced by anything else, at least
https://bugs.kde.org/show_bug.cgi?id=40
Tom Hughes changed:
What|Removed |Added
Summary|Valgrind causes SIGILL due |vex amd64->IR: unhand
https://bugs.kde.org/show_bug.cgi?id=409501
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #5 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=409141
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #3 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=257027
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Resolution|WORKSFORME
https://bugs.kde.org/show_bug.cgi?id=317893
Tom Hughes changed:
What|Removed |Added
Resolution|WORKSFORME |WAITINGFORINFO
CC
https://bugs.kde.org/show_bug.cgi?id=196335
Tom Hughes changed:
What|Removed |Added
Resolution|WORKSFORME |WAITINGFORINFO
--- Comment #8 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=279471
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Resolution|WORKSFORME
https://bugs.kde.org/show_bug.cgi?id=151886
Tom Hughes changed:
What|Removed |Added
Resolution|WORKSFORME |WAITINGFORINFO
CC
https://bugs.kde.org/show_bug.cgi?id=142229
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Resolution|WORKSFORME
https://bugs.kde.org/show_bug.cgi?id=278816
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Resolution|WORKSFORME
https://bugs.kde.org/show_bug.cgi?id=171627
Tom Hughes changed:
What|Removed |Added
Resolution|WORKSFORME |WAITINGFORINFO
--- Comment #6 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=261034
Tom Hughes changed:
What|Removed |Added
Resolution|WORKSFORME |WAITINGFORINFO
--- Comment #6 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=219515
Tom Hughes changed:
What|Removed |Added
Resolution|WORKSFORME |WAITINGFORINFO
--- Comment #6 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=214336
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Resolution|WORKSFORME
https://bugs.kde.org/show_bug.cgi?id=353370
--- Comment #28 from Tom Hughes ---
That latest change isn't actually committed yet ;-)
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=353370
--- Comment #25 from Tom Hughes ---
So actually there is a later commit which does actually implement RDRAND but
only for AVX2 capable CPUs which yours is not. My other point remains correct,
that we won't advertise RDRAND on any machine where we
https://bugs.kde.org/show_bug.cgi?id=353370
--- Comment #24 from Tom Hughes ---
That's badly written - they are not supported but this bug is resolved by
making valgrind's emulation of the cpuid instruction remove the bit which
claims support for them.
So an application which tests for rdrand
https://bugs.kde.org/show_bug.cgi?id=407904
--- Comment #3 from Tom Hughes ---
Actually I guess when it's inlined there is no symbol table entry for that
function so we must be getting the name from the debug data.
It's going to be very messy though - recognising the inline function at all
https://bugs.kde.org/show_bug.cgi?id=407904
--- Comment #2 from Tom Hughes ---
Indeed I rather suspect the compiler has put the function in the symbol table
as "operator bool" without any mangling at all, given that valgrind has printed
it without any mangling.
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=407904
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=407313
Tom Hughes changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution
https://bugs.kde.org/show_bug.cgi?id=407313
--- Comment #3 from Tom Hughes ---
The answer appears to be sys_newstat:
SYSCALL[10855,1](4) sys_newstat ( 0x4ea48e0(/tmp/libfuse_test_LKz1UA),
0x1ffefff1a0 )
Which by the looks of it has not been marked as potentially blocking.
I think we've been
https://bugs.kde.org/show_bug.cgi?id=407313
--- Comment #2 from Tom Hughes ---
Also, the valgrind output would be more useful that the strace. Make sure you
include --trace-syscalls=yes at a minimu,
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=407313
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=407039
--- Comment #2 from Tom Hughes ---
Actually there is a debuglink as well but still it shouldn't be absolute. Can
you do these commands and provide output as well please:
readelf -S /usr/lib/x86_64-linux-gnu/ld-2.29.so
readelf -x .gnu_debuglink /usr
https://bugs.kde.org/show_bug.cgi?id=407039
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=406877
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Severity|normal
https://bugs.kde.org/show_bug.cgi?id=406434
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=406349
--- Comment #2 from Tom Hughes ---
I think those flags were originally introduced in
918c3a7b7e01abedf840c6fa8786df41192bf737 by Jeremy way back in 2003!
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=406349
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=405516
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
Resolution
https://bugs.kde.org/show_bug.cgi?id=403123
Tom Hughes changed:
What|Removed |Added
Summary|vex amd64->IR: unhandled|vex amd64->IR: unh
https://bugs.kde.org/show_bug.cgi?id=403123
Tom Hughes changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REPORTED
https://bugs.kde.org/show_bug.cgi?id=403123
--- Comment #10 from Tom Hughes ---
Well I didn't commit it because I wasn't sure if Julian would prefer to
implement the instruction instead.
Patches are normally reviewed for inclusion before a release in any case.
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=405394
--- Comment #4 from Tom Hughes ---
Well that one doesn't need a PRE_MEM_READ so the fact that it would complain
isn't really relevant.
You should use PRE_MEM_READ before the system call for any memory which will be
read by the system call
https://bugs.kde.org/show_bug.cgi?id=405394
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #1 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=403123
--- Comment #7 from Tom Hughes ---
Created attachment 118681
--> https://bugs.kde.org/attachment.cgi?id=118681=edit
Suppress FSGSBASE feature flag for AVX2 capable CPUs
Try this patch - it should hopefully suppress the FSGSBASE feature for th
https://bugs.kde.org/show_bug.cgi?id=403123
--- Comment #6 from Tom Hughes ---
Also it looks like the issue is that we are advertising a CPU capability in our
feature mask that we don't actually support (the "fsgsbase" feature) so one
quick fix would be for us to mask that out which
https://bugs.kde.org/show_bug.cgi?id=403123
--- Comment #5 from Tom Hughes ---
Right but that function is presumably just assembly that invokes the
instruction explicitly, so it falls in to the "unless that is coming from
assembly code" part of my comment.
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=403123
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #3 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=404842
--- Comment #4 from Tom Hughes ---
Note that while it may have helped you here using volatile does not make this
code in any way thread safe...
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=404842
--- Comment #2 from Tom Hughes ---
This is what TSAN says by the way:
==
WARNING: ThreadSanitizer: data race (pid=23210)
Write of size 4 at 0x00404054 by thread T1:
#0 fn /home/thh/zzz.c:10 (zzz+0x4011e8)
#1 (libtsan.so
https://bugs.kde.org/show_bug.cgi?id=404842
Tom Hughes changed:
What|Removed |Added
Status|REPORTED|RESOLVED
CC
https://bugs.kde.org/show_bug.cgi?id=404069
Tom Hughes changed:
What|Removed |Added
Summary|unhandled instruction 0x66 |vex x86->IR: unhand
https://bugs.kde.org/show_bug.cgi?id=397313
Tom Hughes changed:
What|Removed |Added
CC||t...@compton.nu
--- Comment #5 from Tom Hughes
https://bugs.kde.org/show_bug.cgi?id=401846
Tom Hughes changed:
What|Removed |Added
Summary|Unhandled instruction |vex amd64->IR: unhandled
|by
https://bugs.kde.org/show_bug.cgi?id=401742
--- Comment #10 from Tom Hughes ---
They are shipped because you need to link against them if you are building an
out-of-tree tool. I don't see why it's wrong for them to be LTO enabled though?
If you really want to ship non-LTO builds then you would
https://bugs.kde.org/show_bug.cgi?id=401742
--- Comment #7 from Tom Hughes ---
Right, but those .a's are actually the main valgrind code I think? They're just
temporary artefacts used as part of the build, not something we ship?
So by removing LTO from those you are removing it from most
https://bugs.kde.org/show_bug.cgi?id=401742
--- Comment #5 from Tom Hughes ---
Doesn't that just disable LTO though?
Note that you can already use --enable-lto=no when configuring if you want to
disable it but judging by the comments in the configure scripts distribution
builds are exactly what
201 - 300 of 487 matches
Mail list logo
