[valgrind] [Bug 398445] uninitialized memory false reports on shared memory
https://bugs.kde.org/show_bug.cgi?id=398445 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #6 from Ivo Raisr --- (In reply to Stas Sergeev from comment #5) > Think of the following use-case. > Consider a very silly shm IPC that > uses just one large struct with many > input and output fields. Client fills > in the output fields and copies the > entire struct to the shm buffer. Server > reads it, fills in the input fields > and puts it back to shm. Client reads > the struct back with all fields now > properly initialized. > valgrind in this scenario would still > think some fields are uninitialized > because it can't understand that server > have already replaced the entire content > in this buffer. Yes, indeed. That's why we have syscall and ioctl wrappers in Valgrind. They describe what the other side (kernel) expects from the buffers sent there and in what shape they come back with buffers received. It should be quite easy to extend this mechanism to an arbitrary client-server protocol, be it via shm, sockets or any other IPC. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #20 from Ivo Raisr --- Thank you for your work. This is going to be a useful Valgrind tool. I like the documentation for the latest patch. Reasoning explained well on examples. You could mention that the default behaviour (fail unseen allocations) can be heavily tuned by options which are described later. As regards instrumentation: unfortunately I don't think the current scheme of detecting function entry/return w.r.t. --toggle-fn is going to work. Instruction instrumentation is done by blocks and their processing is mostly orthogonal to the actual execution. I think Callgrind tool solves similar problem - detecting when a function is entered and returned - try to have a look there. I think it still suffers from some limitations on arm architecture, though. For coding style - please use explicit check for NULL or != NULL. For example if (instr_callstack) => if (instr_callstack != NULL) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #14 from Ivo Raisr --- The current exp-allocfail crashes badly on my Ubuntu 18.04 box. When running './vg-in-place --tool=exp-allocfail /bin/date', it crashes at af_main.c:119. That's because i is equal to an equivalent of '-1' (4294967295). You need to fix the code at af_main.c:96 - UInt i; + Int i; With this fix in place, I was able to play with ordinary Linux/UNIX standalone programs. Will try to do 'make dist' and check if everything works ok tomorrow. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #13 from Ivo Raisr --- (In reply to roger.light from comment #8) > Created attachment 114229 [details] > Updated patch with fixes and text callstacks. Looks quite good. There are just few nits: - Please remove trailing whitespace you introduced (a few occurrences). For example 'git am' gives the list. - Please have a space between 'while' and the condition. - Please do better job with fixed size buffers (for example in write_callstack_line). Some times ago, Florian underwent a painful exercise auditing all fixed size buffers. - You can use C99 constructs. - Description for command line option --callstack-file deserves a better wording. - Description for command line option --show-fail-traces should be probably renamed to --show-failed-traces (or simply --show-failed). The sentence should start with capital letter anyway. - Fix indentation of function af_instrument. I will post my findings about using tool in a separate reply. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #10 from Ivo Raisr --- (In reply to Philippe Waroquiers from comment #9) > I am wondering also how much difficult it would be to somewhat more > generalise the tool. > > For example, we might want to make similar tests to check failing syscalls. Injecting failures in general is a very good topic. However given the imminent Valgrind release, we should decide if this exp-tool can make it for 3.14 in its current shape (and with some regtests available) or not. This decision eventually drives the scope... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385409] s390x: z13 vector integer instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=385409 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #19 from Ivo Raisr --- (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 ULong. I believe this violates the strict aliasing rule. Indeed. In short words strict aliasing says you are not allowed to view the same piece of memory through lenses of different types *other* than 'char *'. I debugged once a nasty problem in SPEC2017 CPU due to a strict aliasing violation combined with LTO. The question is also whether strict aliasing is enabled for this compilation unit... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290 --- Comment #7 from Ivo Raisr --- Alright, I think it would be preferable to have --num-callers used instead of --depth. Users are already familiar with --num-callers. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384337] performance improvements to VEX register allocator v2 and v3
https://bugs.kde.org/show_bug.cgi?id=384337 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Ivo Raisr --- Julian, I have closed this bug now. Register allocator v3 has been the default in Valgrid for many months and all the improvements from this bug which made sense have been already implemented. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 396290] [PATCH] Possible tool - allocfail
https://bugs.kde.org/show_bug.cgi?id=396290
Ivo Raisr changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |CONFIRMED
CC||iv...@ivosh.net
--- Comment #5 from Ivo Raisr ---
Thank you for sharing this tool with the Valgrind community.
I can see value of this tool in its systemic way in which it fails the
application and taking a central place in an automated solution for checking
memory allocation problems.
The idea of storing call stacks instead of hashes is of course welcome, as it
is much more user friendly and configurable.
Please could you also fix some small problems in your code, such as using
"naked" C types (char), missing space between 'if' and '{'. Also do not include
system files (fcntl.h) - use Valgrind's own ones (VKI_O_RDONLY etc.).
As regards '--depth' command line argument, please could you explain why
existing --num-callers is not suitable to use?
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 381553] VEX register allocator v3
https://bugs.kde.org/show_bug.cgi?id=381553 --- Comment #75 from Ivo Raisr --- And thank you, Julian, for your guidance. Unfortunately I won't be able to finish the VEX enhancement/rework residing in (I think) vex-jit-hacks-2 branch. Perhaps some brave soul will be able to continue... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 395682] Reading debug info of binaries with readonly PT_LOAD segments
https://bugs.kde.org/show_bug.cgi?id=395682 Ivo Raisr changed: What|Removed |Added CC||ori...@gmx.fr --- Comment #14 from Ivo Raisr --- *** Bug 384727 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384727] [PATCH]valgrind does not support debug info for read only segments (generated by LLD)
https://bugs.kde.org/show_bug.cgi?id=384727 Ivo Raisr changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #6 from Ivo Raisr --- *** This bug has been marked as a duplicate of bug 395682 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384727] [PATCH]valgrind does not support debug info for read only segments (generated by LLD)
https://bugs.kde.org/show_bug.cgi?id=384727 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |ASSIGNED CC||iv...@ivosh.net --- Comment #3 from Ivo Raisr --- Please could you try one of the patches from bug https://bugs.kde.org/show_bug.cgi?id=395682 These two bugs seem to be very similar. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390471] suppression by specification of source-file line number
https://bugs.kde.org/show_bug.cgi?id=390471 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Ivo Raisr --- Fixed in changeset 410d736a9928f535e2591c9d5f32e8e0941f96d8. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=410d736a9928f535e2591c9d5f32e8e0941f96d8 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390471] suppression by specification of source-file line number
https://bugs.kde.org/show_bug.cgi?id=390471 Ivo Raisr changed: What|Removed |Added Attachment #110691|0 |1 is obsolete|| --- Comment #6 from Ivo Raisr --- Created attachment 113569 --> https://bugs.kde.org/attachment.cgi?id=113569&action=edit patch with NEWS updated Patch cleaned up. Tests still pending. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390471] suppression by specification of source-file line number
https://bugs.kde.org/show_bug.cgi?id=390471 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 CC||iv...@ivosh.net Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 197915] 80-bit floats are not supported on x86 and x86-64
https://bugs.kde.org/show_bug.cgi?id=197915 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #33 from Ivo Raisr --- (In reply to Rich Felker from comment #32) > Is something blocking fixing this issue still? Lack of skilled manpower :-) Feel free to work this issue! -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 338252] building valgrind with -flto (link time optimisation) fails
https://bugs.kde.org/show_bug.cgi?id=338252 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #15 from Ivo Raisr --- (In reply to Дилян Палаузов from comment #14) > Autoconf users willing to compile everything with LTO just by calling > ./configure put in /usr/local/etc/config.site: > > CFLAGS="-O3 -fno-fat-lto-objects -flto" CXXFLAGS="-O3 -fno-fat-lto-objects > -flto" LDFLAGS="-Wl,-O1,-s -flto=4" > > And then any ./configure implies LTO. Just as other programs relying on > autoconf doing the right thing do not offer --enable-lto option in > ./configure --help, can be compiled with LTO, valgrind./configure --help > shall not print --enable-lto. Programmer printing on --help "--enable-lto" > don't understand autoconf. This applies also for artificially added -g or > -O2 from configure.ac or contained in Makefile* Thank you for this insight and sharing your approach. It is really helpful to know that other possibilities exists. However I modifying /usr/local/etc/config.site affects all projects build on a box. Also we cannot force Valgrind users and maintainers to modify global configuration file [consider shared build machines, for example in the gcc build farm]. Perhaps a merged approach could be found? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390524] use of 0b prefix for binary constants
https://bugs.kde.org/show_bug.cgi?id=390524 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||iv...@ivosh.net Resolution|--- |WONTFIX --- Comment #3 from Ivo Raisr --- Support for binary constants has been around since gcc 4.3.0 (since 2008, 10 years ago). Also clang supports this notation. I don't see any reason why we need to prefer compatibility with ancient compilers over readability and maintainability. I think your case is a singular one; majority of LTS distros have moved off of such ancient gcc versions long time ago. You can't expect recent version of Valgrind work with an ancient version of the compiler; neither is the case of other toolchain components. There are going to be more and more cases of Valgrind using compiler features available only to reasonably recent compilers. You could get away for now with a simple patch, changing the binary constants into hexadecimal ones, for example. But with the evolution bringing new changes, you could end up with a huge patchset eventually. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390524] use of 0b prefix for binary constants
https://bugs.kde.org/show_bug.cgi?id=390524 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Ivo Raisr --- Pushed as 23185f46a17079fcfca35c2ef335a598812cb23b. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=23185f46a17079fcfca35c2ef335a598812cb23b -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 --- Comment #10 from Ivo Raisr --- :-) There was also a problem with the actual replacement definition. For example wcsnlen had the following: #if defined(VGO_linux) STRNLEN(VG_Z_LIBC_SONAME, wcsnlen) STRNLEN(VG_Z_LIBC_SONAME, __GI_wcsnlen) #endif This could not have worked. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added Attachment #42|0 |1 is obsolete|| --- Comment #8 from Ivo Raisr --- Created attachment 43 --> https://bugs.kde.org/attachment.cgi?id=43&action=edit Add-replacements-for-wmemchr-and-wcsnlen-on-Linux Make wcslen() operate on Int as well. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 --- Comment #7 from Ivo Raisr --- Oh, alright, let's make it Int also for wcslen() so the whole file is consistent. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added Attachment #111086|0 |1 is obsolete|| --- Comment #5 from Ivo Raisr --- Created attachment 42 --> https://bugs.kde.org/attachment.cgi?id=42&action=edit 0001-Add-replacements-for-wmemchr-and-wcsnlen-on-Linux.patch Fixed patch originally from Nick Alcock. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 --- Comment #4 from Ivo Raisr --- Thank you for the patch. I had to make some fixes to make it actually work and do not introduce regressions. Please review the attachment. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388862] Add replacements for wmemchr and wcsnlen on Linux
https://bugs.kde.org/show_bug.cgi?id=388862 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net Summary|false positive of |Add replacements for |__wcsnlen_sse4_1 with glibc |wmemchr and wcsnlen on |2.26|Linux -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390723] make xtree dump files world wide readable, similar to log files
https://bugs.kde.org/show_bug.cgi?id=390723 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #1 from Ivo Raisr --- Fixed in commit c014c2c43669106b4e2aeb6203a2fbe9e3e4ff48. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=c014c2c43669106b4e2aeb6203a2fbe9e3e4ff48 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390723] make xtree dump files world wide readable, similar to log files
https://bugs.kde.org/show_bug.cgi?id=390723 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390723] make xtree dump files world wide readable, similar to log files
https://bugs.kde.org/show_bug.cgi?id=390723 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 390723] New: make xtree dump files world wide readable, similar to log files
https://bugs.kde.org/show_bug.cgi?id=390723
Bug ID: 390723
Summary: make xtree dump files world wide readable, similar to
log files
Product: valgrind
Version: 3.14 SVN
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: general
Assignee: jsew...@acm.org
Reporter: iv...@ivosh.net
Target Milestone: ---
There is no reason why xtree dump files should not be world wide readable,
similar to log files.
Users can always set the corresponding umask to tighten the permissions.
diff --git a/coregrind/m_xtree.c b/coregrind/m_xtree.c
index 7d5766222..217cad9da 100644
--- a/coregrind/m_xtree.c
+++ b/coregrind/m_xtree.c
@@ -377,7 +377,7 @@ static VgFile* xt_open (const HChar* outfilename)
VgFile* fp;
fp = VG_(fopen)(outfilename, VKI_O_CREAT|VKI_O_WRONLY|VKI_O_TRUNC,
- VKI_S_IRUSR|VKI_S_IWUSR);
+ VKI_S_IRUSR|VKI_S_IWUSR|VKI_S_IRGRP|VKI_S_IROTH);
if (fp == NULL) {
VG_(message)(Vg_UserMsg,
"Error: can not open xtree output file `%s'\n",
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 389065] valgrind meets gcc flag -Wlogical-op
https://bugs.kde.org/show_bug.cgi?id=389065 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Ivo Raisr --- Fixed in commit f19a956e0a96b4f6b37c50b00ae24ecf09a7a3f5. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=f19a956e0a96b4f6b37c50b00ae24ecf09a7a3f5 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from Ivo Raisr --- Pushed as commit bd077baa71a40b60dcf0286b9fb89d803323fd93. https://sourceware.org/git/?p=valgrind.git;a=commit;h=bd077baa71a40b60dcf0286b9fb89d803323fd93 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 --- Comment #7 from Ivo Raisr --- Hi Julian, patch with Solaris implementation is attached. The patch has been refreshed to apply cleanly to the latest git HEAD and a NEWS entry added. It is ready to be pushed - let me know if I should do it. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 Ivo Raisr changed: What|Removed |Added Attachment #109872|0 |1 is obsolete|| --- Comment #6 from Ivo Raisr --- Created attachment 109992 --> https://bugs.kde.org/attachment.cgi?id=109992&action=edit Patch with Solaris implementation added -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389065] valgrind meets gcc flag -Wlogical-op
https://bugs.kde.org/show_bug.cgi?id=389065 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |ASSIGNED --- Comment #4 from Ivo Raisr --- The attached patch enables -Wlogical-op (if supported) and fixes an obvious typo. I used https://github.com/mirage/xen/blob/master/tools/libxc/xc_monitor.c for an inspiration. My gcc 7.2.0 on Ubuntu 17.10 did not report a problem in priv/guest_arm_toIR.c with -Wlogical-op. I guess the first reported problem must have been caused by some other factor. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389065] valgrind meets gcc flag -Wlogical-op
https://bugs.kde.org/show_bug.cgi?id=389065 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net --- Comment #3 from Ivo Raisr --- Created attachment 109970 --> https://bugs.kde.org/attachment.cgi?id=109970&action=edit patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #5 from Ivo Raisr --- (In reply to Julian Seward from comment #4) > Addresses all review comments in comments 2 and 3. Ivo, if you are > happy with it, could you please do the Solaris version of > VG_(get_user_milliseconds)? Will do that, Julian. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 389065] valgrind meets gcc flag -Wlogical-op
https://bugs.kde.org/show_bug.cgi?id=389065 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Ivo Raisr --- Thank you for the bug report. Indeed, the second one is a bug in Valgrind code. The first one is not a bug but merely a mental note for maintainer that this piece of code handles both pkhbt (tb == 0) and pkhbt (tb == 1) variants. Would you like to supply a patch for both the occurrences? Would you like to supply a patch for extending Valgrind build with -Wlogical-op (have a look at configure.ac, similar flags are enabled there). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388895] LibVEX_FrontEnd assertion failure: `0 == sizeof(VexGuestX86State) % LibVEX_GUEST_STATE_ALIGN'
https://bugs.kde.org/show_bug.cgi?id=388895 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #3 from Ivo Raisr --- SVN is a past thing. Valgrind lives in GIT now: http://valgrind.org/downloads/repository.html -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385408] s390x: z13 vector "support" instructions not implemented
https://bugs.kde.org/show_bug.cgi?id=385408 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 388493] exp-sgcheck fails on DW_TAG_subrange_type
https://bugs.kde.org/show_bug.cgi?id=388493
Ivo Raisr changed:
What|Removed |Added
CC||iv...@ivosh.net
--- Comment #3 from Ivo Raisr ---
The DWARF problem is highly probably caused by an unimplemented functionality
in parse_type_DIE(). For DW_tag_subrange, the following is handled:
/* Figure out if we have a definite range or not */
if (have_lower && have_upper && (!have_count)) {
boundE.Te.Bound.knownL = True;
boundE.Te.Bound.knownU = True;
boundE.Te.Bound.boundL = lower;
boundE.Te.Bound.boundU = upper;
}
else if (have_lower && (!have_upper) && (!have_count)) {
boundE.Te.Bound.knownL = True;
boundE.Te.Bound.knownU = False;
boundE.Te.Bound.boundL = lower;
boundE.Te.Bound.boundU = 0;
}
else if ((!have_lower) && have_upper && (!have_count)) {
boundE.Te.Bound.knownL = False;
boundE.Te.Bound.knownU = True;
boundE.Te.Bound.boundL = 0;
boundE.Te.Bound.boundU = upper;
}
else if ((!have_lower) && (!have_upper) && (!have_count)) {
boundE.Te.Bound.knownL = False;
boundE.Te.Bound.knownU = False;
boundE.Te.Bound.boundL = 0;
boundE.Te.Bound.boundU = 0;
} else {
/* FIXME: handle more cases */
goto_bad_DIE;
}
So probably implementing the missing case would overcome the reported DWARF
problem.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 Ivo Raisr changed: What|Removed |Added CC||x...@fictionpress.com --- Comment #18 from Ivo Raisr --- *** Bug 328357 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 328357] TBM bextr instruction unsupported vex amd64->IR: unhandled instruction bytes: 0x8F 0xEA 0xF8 0x10 0xEF 0x3 0x5 0x0
https://bugs.kde.org/show_bug.cgi?id=328357 Ivo Raisr changed: What|Removed |Added Resolution|--- |DUPLICATE CC||iv...@ivosh.net Status|UNCONFIRMED |RESOLVED --- Comment #10 from Ivo Raisr --- *** This bug has been marked as a duplicate of bug 381819 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 Ivo Raisr changed: What|Removed |Added CC||sgtcapsl...@lavabit.com --- Comment #17 from Ivo Raisr --- *** Bug 322586 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 322586] Unknown instruction (bextr) in ld-2.15.so with --march=native on AMD FX-8350
https://bugs.kde.org/show_bug.cgi?id=322586 Ivo Raisr changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||iv...@ivosh.net --- Comment #7 from Ivo Raisr --- The patch by "Petr Pisar" has been attached also to bug 381819. *** This bug has been marked as a duplicate of bug 381819 *** -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 --- Comment #16 from Ivo Raisr --- Created attachment 109550 --> https://bugs.kde.org/attachment.cgi?id=109550&action=edit support for TBM bextr Patch originally attached to bug https://bugs.kde.org/show_bug.cgi?id=322586 by "Petr Pisar" titled "support for TBM bextr". -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 381819] amd64: unhandled instruction bextr (0x8F 0xEA 0x78 0x10 0xD0 0x8 0x4) from BMI1
https://bugs.kde.org/show_bug.cgi?id=381819 --- Comment #15 from Ivo Raisr --- (In reply to Bernd Buschinski from comment #14) > any chance we can push/fix/update this to official valgrind? I would happy > to test new patches :) As discussed previously, the patch attached in this bug is not 100% perfect as it does not properly decode all bextr variants. So it is not ready yet to be integrated into Valgrind source code. And as Mark explained in bug 328357: According to https://en.wikipedia.org/wiki/Bit_Manipulation_Instruction_Sets#TBM_.28Trailing_Bit_Manipulation.29 TBM instructions are only supported on a few AMD processors (Piledriver, Steamroller and Excavator). > Btw is this also related to > https://bugs.kde.org/show_bug.cgi?id=328357? Do we have 3 bugreports for > (almost) the same thing? Probably yes. I will make this bug the main one and close the others. My take here is as follows: these instructions are supported only by a few AMD processors and later versions removed the support. So unless the community will be willing to dedicate some engineering time to support properly all the instruction variants, not much will happen. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 387766] asm shifts cause false positive "Conditional jump or move depends on uninitialised value"
https://bugs.kde.org/show_bug.cgi?id=387766 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #2 from Ivo Raisr --- (In reply to Markus Trippelsdorf from comment #0) > Running gcc trunk under valgrind produces many false positives, e.g.: Please provide a simple standalone reproducer. For example, could a part of update_costs_from_copies() be isolated to reproduce the problem? There is also a patch for Valgrind which makes it to spend some extra time to accurately track definedness: https://bugs.kde.org/show_bug.cgi?id=387664 Please could you try to build Valgrind with this patch and then run it with --expensive-definedness-checks=yes (or --expensive-definedness-checks=auto). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 208052] strlcpy error when n = 0
https://bugs.kde.org/show_bug.cgi?id=208052 --- Comment #9 from Ivo Raisr --- Fixed in commit a5af4146e383dd442130905901b046e2cb4b0ed4, https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=a5af4146e383dd442130905901b046e2cb4b0ed4 NEWS updated in commit 4a8ea8908f7171f50ad3fa66346778e2f73e5976 https://sourceware.org/git/gitweb.cgi?p=valgrind.git;a=commit;h=4a8ea8908f7171f50ad3fa66346778e2f73e5976 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 208052] strlcpy error when n = 0
https://bugs.kde.org/show_bug.cgi?id=208052 --- Comment #7 from Ivo Raisr --- Tom, would you mind integrating the fix into Valgrind source code base at this point? Alternatively, I could do it myself - just let me know. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 208052] strlcpy error when n = 0
https://bugs.kde.org/show_bug.cgi?id=208052 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED CC||iv...@ivosh.net --- Comment #5 from Ivo Raisr --- (In reply to Jan Kryl from comment #4) > I hit the same problem with strlcpy on FreeBSD 11 using valgrind-3.10.1 Please could you comment whether the attached patch by Tom works for you? Preferably using Valgrind 3.13. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385939] Optionally exit on the first error
https://bugs.kde.org/show_bug.cgi?id=385939 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Ivo Raisr --- Pushed as commit c46053cc386be5757420abbd4b8a8cc6219ed33f. https://sourceware.org/git/?p=valgrind.git;a=commit;h=c46053cc386be5757420abbd4b8a8cc6219ed33f Thank you for the reworked patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386318] valgrind.org/info/tools.html is missing SGCheck
https://bugs.kde.org/show_bug.cgi?id=386318 Ivo Raisr changed: What|Removed |Added Assignee|jsew...@acm.org |iv...@ivosh.net -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386318] valgrind.org/info/tools.html is missing SGCheck
https://bugs.kde.org/show_bug.cgi?id=386318 Ivo Raisr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ivo Raisr --- Committed in revision 531. Thank you for the patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 376257] helgrind history full speed up using a cached stack
https://bugs.kde.org/show_bug.cgi?id=376257 --- Comment #5 from Ivo Raisr --- Nice work, Philippe! I have just one question. In helgrind/hg_main.c, the last hunk, there is a message containing a weird character: "re-àsetting it to 0". Is this intended? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 386318] valgrind.org/info/tools.html is missing SGCheck
https://bugs.kde.org/show_bug.cgi?id=386318 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr --- These are experimental tools (prefixed with 'exp-'). They have been nearly untouched since their creation. We can document them in "Experimental Tools" section, though. http://valgrind.org/downloads/variants.html would deserve some cleanup and update as well. Please propose a patch. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385939] Optionally exit on the first error
https://bugs.kde.org/show_bug.cgi?id=385939
--- Comment #2 from Ivo Raisr ---
Thank you for the patch and kudos for documenting the new option in the manual.
>From the high level perspective, I have the following comments and questions:
* It is not clear what happens in the XML mode. Is the XML correctly finalized
with --exit-on-first-error=yes?
* Valgrind does not print anything after it encounters the first error with
--exit-on-first-error=yes, even with '-v'. This could be potentially confusing
to the users. However they get what they wanted, anyway.
* There is no test case present in the patch. Please supply a test case which
exercises --exit-on-first-error=yes in text and XML mode. The test case will
belong under none/tests.
>From the lower level perspective, I have the following comments:
* Source code block indentation is 3 spaces (yes, 3 spaces). Please check all
occurrences.
* New option is listed in usage_NORETURN() but
none/tests/cmdline{1,2].stdout.exp do not reflect it. Please run the regression
tests.
* Please do not introduce trailing whitespace.
--
You are receiving this mail because:
You are watching all bug changes.
[valgrind] [Bug 385939] Optionally exit on the first error
https://bugs.kde.org/show_bug.cgi?id=385939 Ivo Raisr changed: What|Removed |Added Component|memcheck|general Summary|Option to exit on first |Optionally exit on the |error |first error -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385939] Option to exit on first error
https://bugs.kde.org/show_bug.cgi?id=385939 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from Ivo Raisr --- I will have a look. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384676] VEX AMD64 backend should list more real registers as available for the register allocator
https://bugs.kde.org/show_bug.cgi?id=384676 Ivo Raisr changed: What|Removed |Added Resolution|--- |WONTFIX Status|ASSIGNED|RESOLVED --- Comment #4 from Ivo Raisr --- Even after bug 384987 has been fixed, the situation did not improve much. Running Memcheck on perf/bz2 [number of instructions]: baseline: total: 44,936,961,809; reg alloc: 168,848,160; ratio: 15.3 patched: total: 44,933,693,157; reg alloc: 177,659,739; ratio: 15.3 Running Memcheck on perf/tinycc: baseline: total: 3,938,404,232; reg alloc: 121,447,931; ratio 16.2 patched: total: 3,939,903,162; reg alloc: 127,930,047; ratio 16.2 With perf/bz2, there is only a very minor improvement. With perf/tinycc there is actually a very minor deterioration. I am abandoning this bug for good. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385843] [PATCH] ARM: mark caller-save VFP registes as trashed by calls
https://bugs.kde.org/show_bug.cgi?id=385843 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED Assignee|jsew...@acm.org |iv...@ivosh.net --- Comment #11 from Ivo Raisr --- We do have a number of test programs under none/tests/arm which are supposed to test VFP. Please could you have a look if your test program would belong into one of these; otherwise add it there. Then post the results of running the regression test suite before and after your changes are applied. I will then take your patch in. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385843] [PATCH] ARM: mark caller-save VFP registes as trashed by calls
https://bugs.kde.org/show_bug.cgi?id=385843 --- Comment #9 from Ivo Raisr --- (In reply to Sindre Aamås from comment #6) > I have not looked at the stats, but the output is as follows. As suspected, there is a code bloat in the generated code because of the additional spilling before helper calls. Ratio before: 15.9 Ratio after: 16.0 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385843] [PATCH] ARM: mark caller-save VFP registes as trashed by calls
https://bugs.kde.org/show_bug.cgi?id=385843 --- Comment #5 from Ivo Raisr --- Your fix touches register allocation. It is crucial that both ARMInstr_Call() and getRRegUniverse_ARM() are kept in sync (hinted in getRRegUniverse_ARM as well) and that register allocator is presented with the workable set of registers. By marking all Q ones as caller saved (trashed for call), register allocator would need to spill them all before the call. This creates a performance penalty and bloats the generated r-code. Would you try running Memcheck on a program which uses 128-bit VFP (q) registers with '--stats=yes' and note the difference on 'ratio' reported? How prevalent are programs utilizing 128-bit VFP registers compared to 64-bit ones? In other words, are compilers (gcc) likely to utilize those registers a lot? A clue for your answer might lie in the document you cited first: "Registers s16-s31 (d8-d15, q4-q7) must be preserved across subroutine calls; registers s0-s15 (d0-d7, q0-q3) do not need to be preserved (and can be used for passing arguments or returning results in standard procedure-call variants). Registers d16-d31 (q8-q15), if present, do not need to be preserved." -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 385843] [PATCH] ARM: mark caller-save VFP registes as trashed by calls
https://bugs.kde.org/show_bug.cgi?id=385843 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #2 from Ivo Raisr --- The comment in getRRegUniverse_ARM() should be more explicit about which registers are caller save and callee save. And if this is indeed the case, then the patch needs to take care of supplying different set of Q registers for register allocator use. Callee saved registers are preferred over caller saved ones. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 --- Comment #21 from Ivo Raisr --- Thank you all for your responses! They were really helpful. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Ivo Raisr --- Pushed as commits: 83cabd32492e6d19d483a63522e4e874fa64b617 074de238d44c0cdaf394489ea69a67b76916fbce https://sourceware.org/git/?p=valgrind.git;a=commit;h=83cabd32492e6d19d483a63522e4e874fa64b617 https://sourceware.org/git/?p=valgrind.git;a=commit;h=074de238d44c0cdaf394489ea69a67b76916fbce -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 --- Comment #19 from Ivo Raisr --- (In reply to Julian Seward from comment #17) > I expect arm(32) would also get a quite big improvement, because > it's also pretty low on registers. [This is not a request to measure, > just random speculation.] Unfortunately I do not have any machine with arm32 architecture. > Assuming power looks sane (the generated code is at least not any bigger > with the patch), and that everything is stable, I suggest you just land > it whenever you like. Actually profiling for the most used 200 blocks in perf/bz2 shows only the following difference: -VexExpansionRatio 228 3228 141 :10 +VexExpansionRatio 228 3196 140 :10 So this means that the majority of the blocks remained the same size; one block is slightly smaller now. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 --- Comment #16 from Ivo Raisr --- I've fixed the problem with duplicate hregIsVirtual() in host_arch_defs.c files. Here are the performance numbers for amd64 and x86: Running inner Memcheck on perf/bz2 (compiled with -O or -O2). Numbers are instruction counts: amd64 -O:total register allocatorratio vanilla: 45,102,001,869 165,978,807 15.5 patches: 44,928,390,448 169,280,398 15.3 amd64 -O2: vanilla: 44,309,403,899 191,289,068 16.5 patches: 44,108,763,444 195,193,491 16.3 x86 -O: vanilla: 48,711,841,474 233,097,543 14.6 patches: 48,077,926,058 235,505,230 14.4 x86 -O2: vanilla: 50,400,479,522 253,382,282 15.1 patches: 49,953,764,975 256,000,363 14.9 In all cases, the new implementation is faster and produces better (compact) code. I will investigate the situation on power and post the results here. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added Attachment #108135|0 |1 is obsolete|| --- Comment #15 from Ivo Raisr --- Created attachment 108171 --> https://bugs.kde.org/attachment.cgi?id=108171&action=edit register allocation -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added Attachment #108134|0 |1 is obsolete|| --- Comment #14 from Ivo Raisr --- Created attachment 108170 --> https://bugs.kde.org/attachment.cgi?id=108170&action=edit refactor MOV coalescing -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 --- Comment #6 from Ivo Raisr --- I've tested on amd64, ppc8le and arm64 architectures. In all cases, the produced code was more compact and overall performance better, when running inner Memcheck on perf/bz2. Numbers are given as instruction count; ratio as reported by Memcheck with '--stats=yes'. amd64: vanilla:45,112,349,784 total; 165,978,807 reg alloc; ratio 15.5 v3-reoder: 44,943,765,809 total; 167,403,237 reg alloc; ratio 15.3 power8le: vanilla:61,928,020,284 total; 351,285,156 reg alloc; ratio 17.0 v3-reorder: 61,919,130,481 total; 343,001,581 reg alloc; ratio 17.0 arm64 [callgrind does not work on this arch]: vanilla:ratio 14.7 v3-reorder: ratio 14.7 Manual inspection of top 200 SB profiled blocks showed VexExpansionRatio always few instructions better than in vanilla. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added Attachment #107964|0 |1 is obsolete|| --- Comment #5 from Ivo Raisr --- Created attachment 108135 --> https://bugs.kde.org/attachment.cgi?id=108135&action=edit register allocation -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added Attachment #107963|0 |1 is obsolete|| --- Comment #4 from Ivo Raisr --- Created attachment 108134 --> https://bugs.kde.org/attachment.cgi?id=108134&action=edit refactor MOV coalescing -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=384337 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384337] performance improvements to VEX register allocator v2 and v3
https://bugs.kde.org/show_bug.cgi?id=384337 Ivo Raisr changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=384987 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 --- Comment #3 from Ivo Raisr --- The only remaining thing is to refactor isMove callbacks in the remaining architectures so that the information is available directly in HRegUsage. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 --- Comment #2 from Ivo Raisr --- Created attachment 107964 --> https://bugs.kde.org/attachment.cgi?id=107964&action=edit register allocation -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added Status|CONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr --- Created attachment 107963 --> https://bugs.kde.org/attachment.cgi?id=107963&action=edit refactor MOV coalescing -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] New: VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Bug ID: 384987 Summary: VEX register allocator: allocate caller-save registers for short lived vregs Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- This is a performance improvement based on Peter Bergner's suggestion: Allocate caller-saved registers for short lived vregs and callee-save registers for vregs which span accross helper calls. This idea is quite simple but MOV coalescing went in the way. The first patch enhances MOV coalescing so it keeps better track of what registers form the coalescing chain. The second patch actually changes find_free_rreg(). With just a minor additional complexity, we get more compact generated code. This not only helps for better performance; it should also help with i-cache misses. Measuring instruction count, running inner Memcheck: perf/bz2: vanilla: 45,112,349,784 total; reg alloc 165,978,807; ratio 15.5 (97,397 -> 1,506,163) coalesce only: 45,120,691,777 total; reg alloc 167,035,575; ratio 15.5 (97,610 -> 1,509,396) both patches: 44,943,765,809 total; reg alloc 167,403,237; ratio 15.3 (97,607 -> 1,493,722) /bin/true: vanilla: 3,514,906,884 total; reg alloc 60,779,126 coalesce only: 3,506,029,832 total; reg alloc 61,242,900 both patches: 3,503,495,437 total; reg alloc 61,395,160 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384987] VEX register allocator: allocate caller-save registers for short lived vregs
https://bugs.kde.org/show_bug.cgi?id=384987 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384337] performance improvements to VEX register allocator v2 and v3
https://bugs.kde.org/show_bug.cgi?id=384337 Ivo Raisr changed: What|Removed |Added Attachment #107674|0 |1 is obsolete|| Attachment #107676|0 |1 is obsolete|| Attachment #107678|0 |1 is obsolete|| Attachment #107711|0 |1 is obsolete|| --- Comment #14 from Ivo Raisr --- Created attachment 107958 --> https://bugs.kde.org/attachment.cgi?id=107958&action=edit Refactor tracking of MOV coalescing. VReg<->VReg MOV coalescing status is now a part of the HRegUsage. This allows register allocation to query it two times without incurring a performance penalty. This in turn allows to better keep track of vreg<->vreg MOV coalescing so that all vregs in the coalesce chain get the effective |dead_before| of the last vreg. A small performance improvement has been observed because this allows to coalesce even spilled vregs (previously only assigned ones). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384732] posix_spawn with glibc 2.25 causes an assertion
https://bugs.kde.org/show_bug.cgi?id=384732 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #8 from Ivo Raisr --- Solaris port had to support "proper" vfork semantics right from the beginning because Solaris libc relies on its proper functioning. So there are some clever workarounds how to "preserve" vfork semantics but translate it to fork() at the same time. Have a look at coregrind/m_syswrap/syswrap-solaris.c and coregrind/vg_preloaded.c, search there for "vfork". Apart from other stuff which goes on there, a pipe is created to communicate error code from child to parent. This in fact emulates shared address space. If I understand it correctly, pipe was used previously for the very same reason in glibc <= 2.24. Perhaps this mechanism can be leveraged in Valgrind for glibc >= 2.25? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384729] __libc_freeres inhibits cross-platform valgrind
https://bugs.kde.org/show_bug.cgi?id=384729 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #2 from Ivo Raisr --- Calling optional __gnu_cxx::__freeres() already leverages weak reference mechanism. So __libc__freeres() could use the same mechanism. After you make __libc_freeres() optional, please delete references to it in README_DEVELOPERS as it would be no longer needed. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384584] Callee saved registers listed first for AMD64, X86, and PPC architectures
https://bugs.kde.org/show_bug.cgi?id=384584 --- Comment #6 from Ivo Raisr --- At the end only %r11 was removed from the list in getRegUsage_AMD64Instr() because it's used overall as a temporary register for destination address. %rax, %rcx, %rdx could in theory be used as allocatable but performance measurements did not prove it worthwhile (see bug 384676). -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384584] Callee saved registers listed first for AMD64, X86, and PPC architectures
https://bugs.kde.org/show_bug.cgi?id=384584 Ivo Raisr changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Ivo Raisr --- Committed as 00d4667295a821fef9eb198abcb0c942dffb6045. https://sourceware.org/git/?p=valgrind.git;a=commitdiff;h=00d4667295a821fef9eb198abcb0c942dffb6045 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384676] VEX AMD64 backend should list more real registers as available for the register allocator
https://bugs.kde.org/show_bug.cgi?id=384676 --- Comment #2 from Ivo Raisr --- Unfortunately performance measurements do not confirm this as a good idea. Measuring Memcheck on perf/bz2, instruction count: v3 baseline: 45,110 M total; 168 M register allocator v3 patched: 45,123 M total; 176 M register allocator v2 baseline: 45,190 M total; 209 M register allocator v2 patched: 45,266 M total; 220 M register allocator Measuring Memcheck on tinycc, instruction count: v3 baseline: 4,155,471 k total; 86,438 k register allocator v3 patched: 4,155,207 k total; 91,193 k register allocator I'd conclude that although two more registers are available to the register allocator, it does not help because: - they are caller saved registers - register allocator needs to iterate over more registers -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384584] Callee saved registers listed first for AMD64, X86, and PPC architectures
https://bugs.kde.org/show_bug.cgi?id=384584 --- Comment #4 from Ivo Raisr --- The part with %rax, %rcx, %rdx, %r11 removal from getRegUsage_AMD64Instr() will be removed from the patch. The reason is explained in greater detail in: Bug 384676 - VEX AMD64 backend should list more real registers as available for the register allocator https://bugs.kde.org/show_bug.cgi?id=384676 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384584] Callee saved registers listed first for AMD64, X86, and PPC architectures
https://bugs.kde.org/show_bug.cgi?id=384584 Ivo Raisr changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=384676 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384676] VEX AMD64 backend should list more real registers as available for the register allocator
https://bugs.kde.org/show_bug.cgi?id=384676 Ivo Raisr changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=384584 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384676] VEX AMD64 backend should list more real registers as available for the register allocator
https://bugs.kde.org/show_bug.cgi?id=384676 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr --- Created attachment 107840 --> https://bugs.kde.org/attachment.cgi?id=107840&action=edit patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384676] VEX AMD64 backend should list more real registers as available for the register allocator
https://bugs.kde.org/show_bug.cgi?id=384676 Ivo Raisr changed: What|Removed |Added Ever confirmed|0 |1 Assignee|jsew...@acm.org |iv...@ivosh.net Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384676] New: VEX AMD64 backend should list more real registers as available for the register allocator
https://bugs.kde.org/show_bug.cgi?id=384676 Bug ID: 384676 Summary: VEX AMD64 backend should list more real registers as available for the register allocator Product: valgrind Version: 3.14 SVN Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: iv...@ivosh.net Target Milestone: --- Currently host_amd64_defs.* list RAX, RCX and RDX as not available to the register allocator. I think this is a mistake and they should be made available. The more Int64 registers available to the register allocator, the better is the final produced code. Running Valgrind regression test suite shows that %rcx and %rdx can be enabled with no problems. For %rax there is some unimplemented functionality (search for FIXME in host_amd64_defs.c) -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 --- Comment #3 from Ivo Raisr --- And also please add the line explanation somewhere. User manual, verbose output... -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384633] Add a simple progress-reporting facility
https://bugs.kde.org/show_bug.cgi?id=384633 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #2 from Ivo Raisr --- Thank you for the patch, Julian. I will implement VG_(get_user_milliseconds)() for Solaris, that's not a problem. However I wonder why allowed values for --progress-interval are only 1..3600? Why not 0, the default? Please also do something with comments around next_report_due_at, they look really scary. This is not the first static variable we have in Valgrind... What happens if a Valgrind'ed process with --progress-interval > 0 is suspended for several minutes? Is the logic in maybe_progress_report() able to cope with this? And the last nit - please use %u for "#thr" formatting instead of "%d". nThreads is UInt. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384584] Callee saved registers listed first for AMD64, X86, and PPC architectures
https://bugs.kde.org/show_bug.cgi?id=384584 Ivo Raisr changed: What|Removed |Added CC||iv...@ivosh.net --- Comment #1 from Ivo Raisr --- Created attachment 107794 --> https://bugs.kde.org/attachment.cgi?id=107794&action=edit patch -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384584] Callee saved registers listed first for AMD64, X86, and PPC architectures
https://bugs.kde.org/show_bug.cgi?id=384584 Ivo Raisr changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=384337 -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384337] performance improvements to VEX register allocator v2 and v3
https://bugs.kde.org/show_bug.cgi?id=384337 Ivo Raisr changed: What|Removed |Added See Also||https://bugs.kde.org/show_b ||ug.cgi?id=384584 -- You are receiving this mail because: You are watching all bug changes.
