You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(3) |
2
|
3
(5) |
4
(9) |
5
(4) |
6
|
|
7
(1) |
8
(8) |
9
(8) |
10
(12) |
11
(12) |
12
(10) |
13
(4) |
|
14
(8) |
15
(9) |
16
(16) |
17
(12) |
18
(5) |
19
(5) |
20
(5) |
|
21
|
22
(13) |
23
(5) |
24
(13) |
25
(1) |
26
(3) |
27
(3) |
|
28
|
29
(1) |
30
(3) |
31
(9) |
|
|
|
|
From: <sv...@va...> - 2017-05-20 17:00:46
|
Author: philippe
Date: Sat May 20 18:00:39 2017
New Revision: 3378
Log:
Fix some warnings reported by PVS studio (see bug 379502)
Modified:
trunk/priv/host_arm64_isel.c
trunk/priv/host_arm_isel.c
trunk/priv/host_mips_isel.c
Modified: trunk/priv/host_arm64_isel.c
==============================================================================
--- trunk/priv/host_arm64_isel.c (original)
+++ trunk/priv/host_arm64_isel.c Sat May 20 18:00:39 2017
@@ -732,7 +732,7 @@
/* Do final checks, set the return values, and generate the call
instruction proper. */
vassert(nGSPTRs == 0 || nGSPTRs == 1);
- vassert(nVECRETs == (retTy == Ity_V128 || retTy == Ity_V256) ? 1 : 0);
+ vassert(nVECRETs == ((retTy == Ity_V128 || retTy == Ity_V256) ? 1 : 0));
vassert(*stackAdjustAfterCall == 0);
vassert(is_RetLoc_INVALID(*retloc));
switch (retTy) {
Modified: trunk/priv/host_arm_isel.c
==============================================================================
--- trunk/priv/host_arm_isel.c (original)
+++ trunk/priv/host_arm_isel.c Sat May 20 18:00:39 2017
@@ -792,7 +792,7 @@
/* Do final checks, set the return values, and generate the call
instruction proper. */
vassert(nGSPTRs == 0 || nGSPTRs == 1);
- vassert(nVECRETs == (retTy == Ity_V128 || retTy == Ity_V256) ? 1 : 0);
+ vassert(nVECRETs == ((retTy == Ity_V128 || retTy == Ity_V256) ? 1 : 0));
vassert(*stackAdjustAfterCall == 0);
vassert(is_RetLoc_INVALID(*retloc));
switch (retTy) {
Modified: trunk/priv/host_mips_isel.c
==============================================================================
--- trunk/priv/host_mips_isel.c (original)
+++ trunk/priv/host_mips_isel.c Sat May 20 18:00:39 2017
@@ -605,7 +605,7 @@
/* Do final checks, set the return values, and generate the call
instruction proper. */
vassert(nGSPTRs == 0 || nGSPTRs == 1);
- vassert(nVECRETs == (retTy == Ity_V128 || retTy == Ity_V256) ? 1 : 0);
+ vassert(nVECRETs == ((retTy == Ity_V128 || retTy == Ity_V256) ? 1 : 0));
vassert(*stackAdjustAfterCall == 0);
vassert(is_RetLoc_INVALID(*retloc));
switch (retTy) {
|
|
From: <sv...@va...> - 2017-05-20 16:13:40
|
Author: philippe
Date: Sat May 20 17:13:33 2017
New Revision: 16402
Log:
Removes a useless part of a condition, as discussed in bug 375415
Modified:
trunk/memcheck/mc_errors.c
Modified: trunk/memcheck/mc_errors.c
==============================================================================
--- trunk/memcheck/mc_errors.c (original)
+++ trunk/memcheck/mc_errors.c Sat May 20 17:13:33 2017
@@ -1098,7 +1098,7 @@
}
/* -- Search for a recently freed block which might bracket it. -- */
mc = MC_(get_freed_block_bracketting)( a );
- if (mc && !MC_(is_mempool_block)(mc)) {
+ if (mc) {
ai->tag = Addr_Block;
ai->Addr.Block.block_kind = Block_Freed;
ai->Addr.Block.block_desc = "block";
|
|
From: Philippe W. <phi...@sk...> - 2017-05-20 15:38:29
|
On Wed, 2017-05-17 at 22:18 +0200, Philippe Waroquiers wrote: After analysis, the below error (and I think also all of the others following) are a false positive. The reason: when running under memcheck, optimised functions such as index are replaced/redirected by valgrind own's equivalent, less optimised, to avoid errors being reported. When an inner tool does not replace index and equivalent, then the outer memcheck detects the false positive due to the inner guest program calling the optimised index. We could maybe avoid such errors, by having the inner tool detecting it is running under an outer memcheck, and then do similar redirection as the outer memcheck. Not too clear how to (easily) do that, so for the momemt, we will just have one more false positive for an outer memcheck. Philippe > ==13472== Conditional jump or move depends on uninitialised value(s) > ==13472== at 0xFE5E48D22: ??? > ==13472== by 0xFE4A60EBF: ??? > ==13472== by 0xFE18192FF: ??? > ==13472== by 0x400A9B6: _dl_new_object (dl-object.c:191) > ==13472== by 0x3808B90F: ??? (m_translate.c:752) > ==13472== by 0x100000000: ??? > ==13472== by 0xFE4A60EA7: ??? > ==13472== by 0xFE4A60EBF: ??? > ==13472== by 0xFE18192FF: ??? > ==13472== by 0x400A9B6: _dl_new_object (dl-object.c:191) > ==13472== by 0xF000155A5: ??? > ==13472== by 0x380D392E: thread_wrapper (syswrap-linux.c:103) > ==13472== by 0x380D392E: run_a_thread_NORETURN (syswrap-linux.c:156) > ==13472== by 0x58084350: _______VVVVVVVV_appended_inner_guest_stack_VVVVVVVV_______ (m_execontext.c:332) > ==13472== by 0x4017784: index (strchr.S:77) > ==13472== by 0x400AA79: _dl_new_object (dl-object.c:205) > ==13472== by 0x4005E43: _dl_map_object_from_fd (dl-load.c:1059) > ==13472== by 0x400805E: _dl_map_object (dl-load.c:2605) > ==13472== by 0x40129E4: dl_open_worker (dl-open.c:235) > ==13472== by 0x400E873: _dl_catch_error (dl-error.c:187) > ==13472== by 0x40123FA: _dl_open (dl-open.c:661) > ==13472== by 0x525502A: dlopen_doit (dlopen.c:66) > ==13472== by 0x400E873: _dl_catch_error (dl-error.c:187) > ==13472== by 0x52555DC: _dlerror_run (dlerror.c:163) > ==13472== by 0x52550C0: dlopen@@GLIBC_2.2.5 (dlopen.c:87) > ==13472== by 0x4007AF: main (dlopen_main.c:13) |
|
From: Philippe W. <phi...@sk...> - 2017-05-20 15:03:26
|
On Thu, 2017-05-18 at 00:40 +0200, Ivo Raisr wrote: > 2017-05-17 23:09 GMT+02:00 Philippe Waroquiers <phi...@sk...>: > > On Wed, 2017-05-17 at 23:03 +0200, Philippe Waroquiers wrote: > >> Not too clear to me what are these adcx* instructions, and if they > >> are supposed to be supported according to the configure test, which > >> checks vmovupd and vaddpd instructions. > > As I understand, adcx instruction is available if adx extension > > is supported. > > > > On my desktop (where the test compile) adx is in /proc/cpuinfo. > > > > But on gcc20, there is no such adx flag. > > > > I imagine we need a specific configure test for BUILD_ADX_TESTS? > > > > What do you think? > > Yes, that would be probably the most sane way how to check binutils capabilities > in this case. In revision 16401, I committed a change that unbreaks the build on gcc20 kind of systems (using a BUILD_ADX_TESTS). Note however that adx capable systems are however reported by V as being non adx capable. I guess a cleaner/full fix/full support for adx implies to change the synthetic cpu hwcaps provided by V (as cpuid reports a non adx capable system) Philippe |
|
From: <sv...@va...> - 2017-05-20 15:00:02
|
Author: philippe
Date: Sat May 20 15:59:54 2017
New Revision: 16401
Log:
Compile fb_test_amd64 only if adx instructions can be compiled
Note: this just unbreaks the build on avx + non_adx capable systems
(such as gcc farm gcc20).
adx capable system should probably be better handled:
* ./tests/x86_amd64_features cannot check for adx flag
(so fb_test_amd64 is run if compiled and system is avx capable, which
might give problems if gcc/as can compile the test, but the cpu
cannot execute adx instructions)
* on an adx capable system, a native run of cpuid tells it is adx capable
but under valgrind, cpuid reports the valgrind synthetic cpu is not adx
capable.
Modified:
trunk/configure.ac
trunk/none/tests/amd64/Makefile.am
Modified: trunk/configure.ac
==============================================================================
--- trunk/configure.ac (original)
+++ trunk/configure.ac Sat May 20 15:59:54 2017
@@ -2661,6 +2661,26 @@
AM_CONDITIONAL(BUILD_MPX_TESTS, test x$ac_have_as_mpx = xyes)
+# does the amd64 assembler understand ADX instructions?
+# Note, this doesn't generate a C-level symbol. It generates a
+# automake-level symbol (BUILD_ADX_TESTS), used in test Makefile.am's
+AC_MSG_CHECKING([if amd64 assembler knows the ADX instructions])
+
+AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[]], [[
+ do {
+ asm ("adcxq %r14,%r8");
+ } while (0)
+]])], [
+ac_have_as_adx=yes
+AC_MSG_RESULT([yes])
+], [
+ac_have_as_adx=no
+AC_MSG_RESULT([no])
+])
+
+AM_CONDITIONAL(BUILD_ADX_TESTS, test x$ac_have_as_adx = xyes)
+
+
# Does the C compiler support the "ifunc" attribute
# Note, this doesn't generate a C-level symbol. It generates a
# automake-level symbol (BUILD_IFUNC_TESTS), used in test Makefile.am's
Modified: trunk/none/tests/amd64/Makefile.am
==============================================================================
--- trunk/none/tests/amd64/Makefile.am (original)
+++ trunk/none/tests/amd64/Makefile.am Sat May 20 15:59:54 2017
@@ -111,8 +111,10 @@
if BUILD_ADDR32_TESTS
check_PROGRAMS += asorep
endif
-if BUILD_AVX_TESTS
+if BUILD_ADX_TESTS
check_PROGRAMS += fb_test_amd64
+endif
+if BUILD_AVX_TESTS
if BUILD_VPCLMULQDQ_TESTS
check_PROGRAMS += avx-1
endif
|