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
(17) |
2
(14) |
3
(15) |
4
(30) |
5
(18) |
6
(12) |
7
(10) |
|
8
(11) |
9
(11) |
10
(14) |
11
(12) |
12
(12) |
13
(8) |
14
(5) |
|
15
(11) |
16
(19) |
17
(15) |
18
(15) |
19
(16) |
20
(9) |
21
(9) |
|
22
(12) |
23
(11) |
24
(10) |
25
(5) |
26
(11) |
27
(12) |
28
(20) |
|
29
(11) |
30
(21) |
|
|
|
|
|
|
From: Julian S. <js...@ac...> - 2008-06-03 22:13:46
|
> Once again I don't see any way for these calls to block (though > select, poll and read on the fd can, of course). > > Hope that helps, It does. Thanks. I'll just mark sync_file_range as might-block (even though only for disk I/O) and leave it at that. J |
|
From: <sv...@va...> - 2008-06-03 20:58:44
|
Author: sewardj
Date: 2008-06-03 21:58:46 +0100 (Tue, 03 Jun 2008)
New Revision: 8176
Log:
Import recent suppression upgrades from 3_3_BRANCH:
revs 8163 8166 8167 8168.
Also, mention glibc-2.X.supp.in in Makefile.am so it gets included
in the distro tarball.
Modified:
trunk/Makefile.am
trunk/glibc-2.X.supp.in
trunk/xfree-4.supp
Modified: trunk/Makefile.am
===================================================================
--- trunk/Makefile.am 2008-06-03 15:12:59 UTC (rev 8175)
+++ trunk/Makefile.am 2008-06-03 20:58:46 UTC (rev 8176)
@@ -21,7 +21,8 @@
SUPP_FILES = \
glibc-2.2.supp glibc-2.3.supp glibc-2.4.supp glibc-2.5.supp \
- glibc-2.6.supp glibc-2.7.supp aix5libc.supp xfree-3.supp xfree-4.supp \
+ glibc-2.6.supp glibc-2.7.supp glibc-2.X.supp.in \
+ aix5libc.supp xfree-3.supp xfree-4.supp \
glibc-2.34567-NPTL-helgrind.supp \
glibc-2.2-LinuxThreads-helgrind.supp \
glibc-2.X-drd.supp
Modified: trunk/glibc-2.X.supp.in
===================================================================
--- trunk/glibc-2.X.supp.in 2008-06-03 15:12:59 UTC (rev 8175)
+++ trunk/glibc-2.X.supp.in 2008-06-03 20:58:46 UTC (rev 8176)
@@ -3,6 +3,9 @@
# Errors to suppress by default with glibc @GLIBC_VERSION@.x
+# IMPORTANT: DO NOT EDIT glibc-2.X.supp, as it is as a generated
+# file. Instead edit glibc-2.X.supp.in.
+
# Format of this file is:
# {
# name_of_suppression
@@ -23,62 +26,87 @@
# and the optional extra info is:
# if Param: name of system call param
+##----------------------------------------------------------------------##
+##--- generic suppressions ---##
+##----------------------------------------------------------------------##
+
{
- dl-hack1
+ dl-hack3-cond-1
Memcheck:Cond
- fun:_dl_start
- fun:_start
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
}
-
{
- dl-hack2
+ dl-hack3-cond-2
Memcheck:Cond
- obj:/lib*/ld-@GLIBC_VERSION@*.so
- obj:/lib*/ld-@GLIBC_VERSION@*.so
- obj:/lib*/ld-@GLIBC_VERSION@*.so
- obj:/lib*/ld-@GLIBC_VERSION@*.so
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/libc-@GLIBC_VERSION@*.so*
}
-
{
- dl-hack3-1
+ dl-hack3-cond-3
Memcheck:Cond
obj:/lib*/ld-@GLIBC_VERSION@*.so*
- obj:/lib*/ld-@GLIBC_VERSION@*.so*
- obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/libc-@GLIBC_VERSION@*.so*
+ obj:/lib*/libc-@GLIBC_VERSION@*.so*
}
{
- dl-hack3-2
+ dl-hack3-cond-4
Memcheck:Cond
obj:/lib*/ld-@GLIBC_VERSION@*.so*
obj:/lib*/ld-@GLIBC_VERSION@*.so*
- obj:/lib*/libc-@GLIBC_VERSION@*.so*
+ obj:/lib*/libdl-@GLIBC_VERSION@*.so*
}
{
- dl-hack4-64bit-1
+ dl-hack4-64bit-addr-1
Memcheck:Addr8
- obj:/lib64/ld-@GLIBC_VERSION@*.so*
- obj:/lib64/ld-@GLIBC_VERSION@*.so*
- obj:/lib64/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
}
{
- dl-hack4-64bit-2
+ dl-hack4-64bit-addr-2
Memcheck:Addr8
- obj:/lib64/ld-@GLIBC_VERSION@*.so*
- obj:/lib64/ld-@GLIBC_VERSION@*.so*
- obj:/lib64/libc-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/libc-@GLIBC_VERSION@*.so*
}
{
- dl-hack4-64bit-3
+ dl-hack4-64bit-addr-3
Memcheck:Addr8
- obj:/lib64/ld-@GLIBC_VERSION@*.so*
- obj:/lib64/ld-@GLIBC_VERSION@*.so*
- obj:/lib64/libdl-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so*
+ obj:/lib*/libdl-@GLIBC_VERSION@*.so*
}
+{
+ dl-hack5-32bit-addr-1
+ Memcheck:Addr4
+ obj:/lib*/ld-@GLIBC_VERSION@*.so
+ obj:/lib*/ld-@GLIBC_VERSION@*.so
+ obj:/lib*/ld-@GLIBC_VERSION@*.so
+}
+{
+ dl-hack5-32bit-addr-3
+ Memcheck:Addr4
+ obj:/lib*/ld-@GLIBC_VERSION@*.so
+ obj:/lib*/ld-@GLIBC_VERSION@*.so
+ obj:/lib*/libdl-@GLIBC_VERSION@*.so*
+}
+{
+ dl-hack5-32bit-addr-4
+ Memcheck:Addr4
+ obj:/lib*/ld-@GLIBC_VERSION@*.so
+ obj:/lib*/libdl-@GLIBC_VERSION@*.so*
+ obj:/lib*/ld-@GLIBC_VERSION@*.so
+}
##----------------------------------------------------------------------##
+##--- Misc ad-hoc hacks ---##
+##----------------------------------------------------------------------##
{
glibc-2.5.x-on-SUSE-10.2-(PPC)-1
Memcheck:Cond
Modified: trunk/xfree-4.supp
===================================================================
--- trunk/xfree-4.supp 2008-06-03 15:12:59 UTC (rev 8175)
+++ trunk/xfree-4.supp 2008-06-03 20:58:46 UTC (rev 8176)
@@ -214,8 +214,40 @@
fun:_XSend
}
+{
+ X on SUSE11 writev uninit padding
+ Memcheck:Param
+ writev(vector[...])
+ fun:writev
+ obj:/usr/lib*/libxcb.so*
+ obj:/usr/lib*/libxcb.so*
+}
+{
+ X on SUSE11 writev uninit padding 2
+ Memcheck:Param
+ writev(vector[...])
+ obj:/lib*/ld-2.*.so*
+ obj:/usr/lib*/libxcb.so*
+ obj:/usr/lib*/libxcb.so*
+}
+{
+ X on SUSE11 writev uninit padding 3
+ Memcheck:Param
+ writev(vector[...])
+ obj:/lib*/ld-2.*.so*
+ obj:/usr/lib*/libORBit*.so*
+ obj:/usr/lib*/libORBit*.so*
+}
+{
+ X on SUSE11 writev uninit padding 4
+ Memcheck:Param
+ writev(vector[...])
+ obj:/lib*/libc-2.*.so*
+ obj:/usr/lib*/libORBit*.so*
+ obj:/usr/lib*/libORBit*.so*
+}
+
-
# There's something strange about a % 127 in XftFontOpenInfo
# (hashing) which gcc turns into a multiply by 33818641 and
# some other guff instead. I don't understand it enough to
|
|
From: Bart V. A. <bar...@gm...> - 2008-06-03 18:33:42
|
On Mon, Jun 2, 2008 at 11:01 AM, Julian Seward <js...@ac...> wrote:
> It would be easy enough to modify vex to pass supply the relevant info,
> for example
>
> * for load instructions, whether they are a normal load or a lwarx
> * for store instructions, the same
>
> plus the tool gets to see all loads and stores anyway, if it wants.
>
> It seems to me that the above is not the real problem. The real problem
> is, even if you have all that information available, how can it be used
> to infer which pieces of memory are being atomically modified?
The aforementioned information could be used by a tool as follows:
1. Assume that lwarx and stwcx instructions are always used as
follows: do { lwarx ...; stwcx ...; } while (reservation failed);
2. Given the above assumption, if the stwcx instruction performed a
store, then it was an atomic store.
I'm not sure however that (1) is the only way in which lwarx and stwcx
instructions are used.
Bart.
|
|
From: Rich C. <Ric...@me...> - 2008-06-03 16:55:43
|
Compiled, built, and tested:
Slackware 12.1 i686 smp
== 302 tests, 21 stderr failures, 4 stdout failures, 0 post failures ==
openSUSE 10.2 x86_64 smp
== 336 tests, 59 stderr failures, 50 stdout failures, 0 post failures ==
No problems for the simple test program I ran.
One of my test programs SIGSEGV, but I think that has more to do with the
flakiness in the program than with anythin in V.
R.
On Mon, 2 Jun 2008 11:53:36 +0200
Julian Seward <js...@ac...> wrote:
>
> I have put a release candidate for 3.3.1 at
>
> http://www.valgrind.org/downloads/valgrind-3.3.1.RC1.tar.bz2
> (md5 = 7b8325af2156c679d825d15eb38a0bd4)
>
> Please download and try it on platforms that are important to you, and
> let me know of any critical breakage. If no critical problems are
> reported, I plan to make make the final 3.3.1 release on Wednesday 4 June.
>
> For your convenience, the 3.3.1 release notes are attached below. The
> main important change is support for glibc-2.8 systems. In particular
> this tarball works well on Fedora 9, openSUSE 11, and Ubuntu 8.04.
>
> J
>
>
> Release 3.3.1 (4 June 2008)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 3.3.1 fixes a bunch of bugs in 3.3.0, adds support for glibc-2.8 based
> systems (openSUSE 11, Fedora Core 9), improves the existing glibc-2.7
> support, and adds support for the SSSE3 (Core 2) instruction set.
>
> 3.3.1 will likely be the last release that supports some very old
> systems. In particular, the next major release, 3.4.0, will drop
> support for the old LinuxThreads threading library, and for gcc
> versions prior to 3.0.
>
> The fixed bugs are as follows. Note that "n-i-bz" stands for "not in
> bugzilla" -- that is, a bug that was reported to us but never got a
> bugzilla entry. We encourage you to file bugs in bugzilla
> (http://bugs.kde.org/enter_valgrind_bug.cgi) rather than mailing the
> developers (or mailing lists) directly -- bugs that are not entered
> into bugzilla tend to get forgotten about or ignored.
>
> n-i-bz Massif segfaults at exit
> n-i-bz Memcheck asserts on Altivec code
> n-i-bz fix sizeof bug in Helgrind
> n-i-bz check fd on sys_llseek
> n-i-bz update syscall lists to kernel 2.6.23.1
> n-i-bz support sys_sync_file_range
> n-i-bz handle sys_sysinfo, sys_getresuid, sys_getresgid on ppc64-linux
> n-i-bz intercept memcpy in 64-bit ld.so's
> n-i-bz Fix wrappers for sys_{futimesat,utimensat}
> n-i-bz Minor false-error avoidance fixes for Memcheck
> n-i-bz libmpiwrap.c: add a wrapper for MPI_Waitany
> n-i-bz helgrind support for glibc-2.8
> n-i-bz partial fix for mc_leakcheck.c:698 assert:
> 'lc_shadows[i]->data + lc_shadows[i] ...
> n-i-bz Massif/Cachegrind output corruption when programs fork
> n-i-bz register allocator fix: handle spill stores correctly
> n-i-bz add support for PA6T PowerPC CPUs
> 126389 vex x86->IR: 0xF 0xAE (FXRSTOR)
> 158525 ==126389
> 152818 vex x86->IR: 0xF3 0xAC (repz lodsb)
> 153196 vex x86->IR: 0xF2 0xA6 (repnz cmpsb)
> 155011 vex x86->IR: 0xCF (iret)
> 155091 Warning [...] unhandled DW_OP_ opcode 0x23
> 156960 ==155901
> 155528 support Core2/SSSE3 insns on x86/amd64
> 155929 ms_print fails on massif outputs containing long lines
> 157665 valgrind fails on shmdt(0) after shmat to 0
> 157748 support x86 PUSHFW/POPFW
> 158212 helgrind: handle pthread_rwlock_try{rd,wr}lock.
> 158425 sys_poll incorrectly emulated when RES==0
> 158744 vex amd64->IR: 0xF0 0x41 0xF 0xC0 (xaddb)
> 160907 Support for a couple of recent Linux syscalls
> 161285 Patch -- support for eventfd() syscall
> 161378 illegal opcode in debug libm (FUCOMPP)
> 160136 ==161378
> 161487 number of suppressions files is limited to 10
> 162386 ms_print typo in milliseconds time unit for massif
> 161036 exp-drd: client allocated memory was never freed
> 162663 signalfd_wrapper fails on 64bit linux
>
> (3.3.1.RC1: 2 June 2008, vex r1854, valgrind r8169).
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
>
--
Rich Coe ric...@me...
Virtual Principle Engineer General Electric Healthcare Technologies
Global Software Platforms, Computer Technology Team
|
|
From: <sv...@va...> - 2008-06-03 15:12:58
|
Author: bart
Date: 2008-06-03 16:12:59 +0100 (Tue, 03 Jun 2008)
New Revision: 8175
Log:
Added Cholesky and FFT.
Modified:
trunk/exp-drd/scripts/run-splash2
Modified: trunk/exp-drd/scripts/run-splash2
===================================================================
--- trunk/exp-drd/scripts/run-splash2 2008-06-03 11:41:19 UTC (rev 8174)
+++ trunk/exp-drd/scripts/run-splash2 2008-06-03 15:12:59 UTC (rev 8175)
@@ -4,6 +4,32 @@
# Function definitions #
########################
+function log2 {
+ local i
+
+ for ((i=0;i<64;i++))
+ do
+ if [ $((2**i)) = $1 ]; then
+ echo $i
+ return 0
+ fi
+ done
+ echo ""
+ return 1
+}
+
+function get_cache_size {
+ local s
+ s=$(</sys/devices/system/cpu/cpu0/cache/index2/size)
+ if [ "${s%M}" != "$s" ]; then
+ echo $((${s%M}*1024*1024))
+ elif [ "${s%K}" != "$s" ]; then
+ echo $((${s%K}*1024))
+ else
+ echo $s
+ fi
+}
+
# Read a stream of numbers from stdin (one per line), and print the average
# and standard deviation.
function avgstddev {
@@ -42,14 +68,19 @@
# Script body
-SPLASH2="$(dirname $0)/../splash2"
+DRD_SCRIPTS_DIR="$(dirname $0)"
+if [ "${DRD_SCRIPTS_DIR}" = "." ]; then
+ DRD_SCRIPTS_DIR="$PWD"
+fi
+
+SPLASH2="${DRD_SCRIPTS_DIR}/../splash2"
if [ ! -e "${SPLASH2}" ]; then
echo "Error: splash2 directory not found (${SPLASH2})."
exit 1
fi
if [ "$VG" = "" ]; then
- VG="$(dirname $0)/../../vg-in-place"
+ VG="${DRD_SCRIPTS_DIR}/../../vg-in-place"
fi
if [ ! -e "$VG" ]; then
@@ -57,18 +88,45 @@
exit 1
fi
-# Results: (-p1) (-p2) (-p3) (-p4) ITC (-p4)
-# lu, contiguous blocks: 40 48 53 55 420
-# lu, non-contiguous blocks: 37 47 55 58 420
-# radiosity: 99 99 99 99 490
+# Results: (-p1) (-p2) (-p3) (-p4) ITC (-p4) ITC (-p4)
+# original w/ filter
+# .........................................................................
+# Cholesky 46 59 75 92 239 82
+# FFT 15 90 41
+# LU, contiguous blocks 40 48 53 55 428 128
+# LU, non-contiguous blocks 37 47 55 58 428 128
+# Ocean 90 28
+# Radiosity 99 99 99 99 485 163
+# Radix 222 56
+# Raytrace 172 53
+# Water-n2 189 39
+# Water-sp 183 34
-# lu, contiguous blocks.
+cache_size=$(get_cache_size)
+log2_cache_size=$(log2 ${cache_size})
+
+# Cholesky
+if false; then
+(
+ cd ${SPLASH2}/codes/kernels/cholesky
+ if [ ! -e inputs/tk29.O ]; then
+ gzip -cd < inputs/tk29.O.Z > inputs/tk29.O
+ fi
+ run_test ./CHOLESKY -C${cache_size} -n1024 inputs/tk29.O
+)
+fi
+
+# FFT
+run_test ${SPLASH2}/codes/kernels/fft/FFT -l${log2_cache_size} -m$((2**28))
+exit 1
+
+# LU, contiguous blocks.
run_test ${SPLASH2}/codes/kernels/lu/contiguous_blocks/LU -n1024
-# lu, non-contiguous blocks.
+# LU, non-contiguous blocks.
run_test ${SPLASH2}/codes/kernels/lu/non_contiguous_blocks/LU -n1024
-# radiosity.
+# Radiosity.
run_test ${SPLASH2}/codes/apps/radiosity/RADIOSITY -batch -room
|
|
From: Paul M. <pa...@sa...> - 2008-06-03 12:46:30
|
Julian Seward writes: > Anybody know anything about utimensat and timerfd_* ? utimensat is a fancy version of utime() or utimes() that takes timespecs for the times (i.e. seconds and nanoseconds) and also lets you specify a file descriptor that the kernel will use as the "current" directory if the filename you give is a relative path. The prototype is long utimensat(int dir_fd, char *filename, struct timespec *times, int flags) If dir_fd == AT_FDCWD (-100) then the process current directory is used. The only flag that is valid is AT_SYMLINK_NOFOLLOW (0x100). I don't see how it could block except possibly for disk I/O. The timerfd stuff lets you get a file descriptor that you can do poll or select on, which is associated with a timer and will become ready when the timer expires, as I understand it. timerfd_create creates one of these things, timerfd_settime sets how long before it expires, and timerfd_gettime tells you how much time is left. The prototypes are: long timerfd_create(int clockid, int flags); where clockid is CLOCK_MONOTONIC or CLOCK_REALTIME and flags currently has to be 0; long timerfd_settime(int fd, int flags, const struct itimerspec *itimer, struct itimerspec *otimer); long timerfd_gettime(int fd, struct itimerspec *otimer); and a struct itimerspec has an it_interval and it_value like a struct itimerval but with seconds and nanoseconds. Once again I don't see any way for these calls to block (though select, poll and read on the fd can, of course). Hope that helps, Paul. |
|
From: <sv...@va...> - 2008-06-03 11:41:16
|
Author: bart
Date: 2008-06-03 12:41:19 +0100 (Tue, 03 Jun 2008)
New Revision: 8174
Log:
Made script more robusts. Ratio is now always computed relative to the non-Valgrind single-CPU run.
Modified:
trunk/exp-drd/scripts/run-splash2
Modified: trunk/exp-drd/scripts/run-splash2
===================================================================
--- trunk/exp-drd/scripts/run-splash2 2008-06-02 17:38:43 UTC (rev 8173)
+++ trunk/exp-drd/scripts/run-splash2 2008-06-03 11:41:19 UTC (rev 8174)
@@ -22,16 +22,18 @@
read avg1 stddev1 < "$tmp"
echo "Average time: ${avg1} +/- ${stddev1} seconds"
- echo "$VG --tool=exp-drd $@"
- for ((i=0;i<3;i++))
+ for ((p=1; p<=4; p++))
do
- /usr/bin/time --format="%e" $VG --tool=exp-drd "$@" 2>&1 | tail -n 1
- done | avgstddev > "$tmp"
- read avg2 stddev2 < "$tmp"
- echo "Average time: ${avg2} +/- ${stddev2} seconds"
+ echo "$VG --tool=exp-drd $@ -p$p"
+ for ((i=0;i<3;i++))
+ do
+ /usr/bin/time --format="%e" $VG --tool=exp-drd "$@" -p$p 2>&1 | tail -n 1
+ done | avgstddev > "$tmp"
+ read avg2 stddev2 < "$tmp"
+ echo "Average time: ${avg2} +/- ${stddev2} seconds"
+ awk "END{print "'"'"Ratio ="'"'", ${avg2}/${avg1}, "'"'"+/-"'"'", ${avg2}/${avg1}*(${stddev1}/${avg1}+${stddev2}/${avg2})}" </dev/null
+ done
- awk "END{print "'"'"Ratio ="'"'", ${avg2}/${avg1}, "'"'"+/-"'"'", ${avg2}/${avg1}*(${stddev1}/${avg1}+${stddev2}/${avg2})}" </dev/null
-
echo ''
rm -f "$tmp"
@@ -40,13 +42,14 @@
# Script body
-if [ ! -e splash2 ]; then
- echo "Error: splash2 directory not found."
+SPLASH2="$(dirname $0)/../splash2"
+if [ ! -e "${SPLASH2}" ]; then
+ echo "Error: splash2 directory not found (${SPLASH2})."
exit 1
fi
if [ "$VG" = "" ]; then
- VG=../vg-in-place
+ VG="$(dirname $0)/../../vg-in-place"
fi
if [ ! -e "$VG" ]; then
@@ -54,22 +57,21 @@
exit 1
fi
-# Results (-p1): exp-drd (-p1) (-p2) (-p4) ITC (-p4)
-# lu, contiguous blocks: 39 43 46 420
-# lu, non-contiguous blocks: 34 41 48 420
-# radiosity: 99 490
+# Results: (-p1) (-p2) (-p3) (-p4) ITC (-p4)
+# lu, contiguous blocks: 40 48 53 55 420
+# lu, non-contiguous blocks: 37 47 55 58 420
+# radiosity: 99 99 99 99 490
# lu, contiguous blocks.
-run_test splash2/codes/kernels/lu/contiguous_blocks/LU -p1 -n1024
-run_test splash2/codes/kernels/lu/contiguous_blocks/LU -p2 -n1024
-run_test splash2/codes/kernels/lu/contiguous_blocks/LU -p4 -n1024
+run_test ${SPLASH2}/codes/kernels/lu/contiguous_blocks/LU -n1024
# lu, non-contiguous blocks.
-run_test splash2/codes/kernels/lu/non_contiguous_blocks/LU -p1 -n1024
-run_test splash2/codes/kernels/lu/non_contiguous_blocks/LU -p2 -n1024
-run_test splash2/codes/kernels/lu/non_contiguous_blocks/LU -p4 -n1024
+run_test ${SPLASH2}/codes/kernels/lu/non_contiguous_blocks/LU -n1024
# radiosity.
-run_test splash2/codes/apps/radiosity/RADIOSITY -p1 -batch -room
-run_test splash2/codes/apps/radiosity/RADIOSITY -p2 -batch -room
-run_test splash2/codes/apps/radiosity/RADIOSITY -p4 -batch -room
+run_test ${SPLASH2}/codes/apps/radiosity/RADIOSITY -batch -room
+
+
+# Local variables:
+# compile-command: "./run-splash2"
+# End:
|
|
From: Bart V. A. <bar...@gm...> - 2008-06-03 11:08:27
|
On Tue, Jun 3, 2008 at 12:45 PM, Julian Seward <js...@ac...> wrote: > > Anybody know anything about utimensat and timerfd_* ? I'm not sure this is the answer you want to hear, but the way I found out more information about these system calls is by reading the LKML discussions about these calls, by reverse engineering the kernel sources (Linus' git repository, fs/time.c) and by reading LWN.net. Bart. |
|
From: Julian S. <js...@ac...> - 2008-06-03 10:51:41
|
3.3.1 (and the trunk) add support for a number of new syscalls: epoll_pwait eventfd timerfd_create timerfd_gettime timerfd_settime sync_file_range signalfd utimensat (I thought there were more, but I generated this list by diffing a 3.3.0 tree against the 3.3.1.RC1 tree. Shout if I missed any.) Of these, only PRE(sys_epoll_pwait) has the line "*flags |= SfMayBlock;", which directs valgrind to run the syscall in such a way that other threads can proceed if the syscall blocks. None of the other wrappers have this. So there is a chance (unlikely, but possible) that threaded programs using the others could hang, in the case where a thread does a syscall, and it blocks until some other thread runs. So my question is: which of these syscalls should get an SfMayBlock annotation? What I have so far is: epoll_pwait -- already has it eventfd -- probably OK without timerfd_create -- can't find any docs (no man page on Fedora 9) timerfd_gettime -- can't find any docs (no man page on Fedora 9) timerfd_settime -- can't find any docs (no man page on Fedora 9) sync_file_range -- requires SfMayBlock signalfd -- probably OK without utimensat -- can't find any docs (no man page on Fedora 9) Technically sync_file_range doesn't really require it, since it can presumably always complete without any activity from any other thread. But requiring this could cause pointless arbitrary delays, so it seems best to add it. All the other sync-style wrappers have it. Anybody know anything about utimensat and timerfd_* ? J |
|
From: Julian S. <js...@ac...> - 2008-06-03 07:34:21
|
On Tuesday 03 June 2008 01:16, Dan Kegel wrote: > On Sun, May 4, 2008 at 4:54 PM, Julian Seward <js...@ac...> wrote: > > [new option --track-origins=yes] > > This functionality was inspired by the work of Bond, Nethercote, > > et al, as reported in the paper "Tracking Bad Apples: Reporting > > the Origin of Null and Undefined Value Errors" > > (http://www.valgrind.org/docs/origin-tracking2007.pdf), > > This new feature kicks ass. Wine is starting to get a fair bit of > use out of it. Good! Under the hood, the implementation uses a certain amount of approximation of origin info in some corner cases, in order to keep the performance overheads to reasonable levels. Consequently I would be interested to hear if you see any cases where the presented origins are either wrong, or missing. J |
|
From: Tom H. <th...@cy...> - 2008-06-03 02:57:40
|
Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-06-03 03:20:06 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 437 tests, 6 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 437 tests, 7 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Jun 3 03:39:08 2008 --- new.short Tue Jun 3 03:57:46 2008 *************** *** 8,10 **** ! == 437 tests, 7 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) --- 8,10 ---- ! == 437 tests, 6 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) *************** *** 15,17 **** helgrind/tests/tc20_verifywrap (stderr) - helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) --- 15,16 ---- |
|
From: Tom H. <th...@cy...> - 2008-06-03 02:45:57
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-06-03 03:05:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 431 tests, 4 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-06-03 02:41:56
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-06-03 03:25:04 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 435 tests, 6 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-06-03 02:38:38
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-06-03 03:10:06 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 431 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-06-03 02:23:24
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-06-03 03:00:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 437 tests, 30 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/amd64/insn_ssse3 (stdout) none/tests/amd64/insn_ssse3 (stderr) none/tests/amd64/ssse3_misaligned (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Dan K. <da...@ke...> - 2008-06-02 23:16:27
|
On Sun, May 4, 2008 at 4:54 PM, Julian Seward <js...@ac...> wrote: > [new option --track-origins=yes] > This functionality was inspired by the work of Bond, Nethercote, > et al, as reported in the paper "Tracking Bad Apples: Reporting > the Origin of Null and Undefined Value Errors" > (http://www.valgrind.org/docs/origin-tracking2007.pdf), This new feature kicks ass. Wine is starting to get a fair bit of use out of it. Thanks! - Dan |
|
From: Bart V. A. <bar...@gm...> - 2008-06-02 18:12:24
|
On Mon, Jun 2, 2008 at 11:53 AM, Julian Seward <js...@ac...> wrote: > > I have put a release candidate for 3.3.1 at > http://www.valgrind.org/downloads/valgrind-3.3.1.RC1.tar.bz2 > (md5 = 7b8325af2156c679d825d15eb38a0bd4) By this time I have made a minor exp-drd documentation fix. I'm not expecting that you rebuild the RC tarball because of this, but in case the tarball has to be rebuilt, it would be nice if that fix could be included. Bart. |
|
From: <sv...@va...> - 2008-06-02 17:38:43
|
Author: bart Date: 2008-06-02 18:38:43 +0100 (Mon, 02 Jun 2008) New Revision: 8173 Log: Documentation fixes. Modified: branches/VALGRIND_3_3_BRANCH/exp-drd/docs/README.txt Modified: branches/VALGRIND_3_3_BRANCH/exp-drd/docs/README.txt =================================================================== --- branches/VALGRIND_3_3_BRANCH/exp-drd/docs/README.txt 2008-06-02 07:14:20 UTC (rev 8172) +++ branches/VALGRIND_3_3_BRANCH/exp-drd/docs/README.txt 2008-06-02 17:38:43 UTC (rev 8173) @@ -1,7 +1,7 @@ DRD: a Data Race Detector ========================= -Last update: December 3, 2007 by Bart Van Assche. +Last update: June 2, 2008 by Bart Van Assche. The Difficulty of Multithreading Programming @@ -48,7 +48,7 @@ How to use DRD -------------- -To use this tool, specify --tool=drd on the Valgrind command line. +To use this tool, specify --tool=exp-drd on the Valgrind command line. Future DRD Versions |
|
From: Ashley P. <api...@co...> - 2008-06-02 10:10:54
|
On Mon, 2008-06-02 at 11:53 +0200, Julian Seward wrote: > I have put a release candidate for 3.3.1 at > > http://www.valgrind.org/downloads/valgrind-3.3.1.RC1.tar.bz2 > (md5 = 7b8325af2156c679d825d15eb38a0bd4) > > Please download and try it on platforms that are important to you, and > let me know of any critical breakage. If no critical problems are > reported, I plan to make make the final 3.3.1 release on Wednesday 4 June. Could you apply this patch to re-enable the log file qualifier in the xml output. Also did the VPATH build issue get fixed? It's not hard to do it but it means adding and removing files so it's not something I can send as a patch. Ashley, |
|
From: Julian S. <js...@ac...> - 2008-06-02 10:00:02
|
I have put a release candidate for 3.3.1 at http://www.valgrind.org/downloads/valgrind-3.3.1.RC1.tar.bz2 (md5 = 7b8325af2156c679d825d15eb38a0bd4) Please download and try it on platforms that are important to you, and let me know of any critical breakage. If no critical problems are reported, I plan to make make the final 3.3.1 release on Wednesday 4 June. For your convenience, the 3.3.1 release notes are attached below. The main important change is support for glibc-2.8 systems. In particular this tarball works well on Fedora 9, openSUSE 11, and Ubuntu 8.04. J Release 3.3.1 (4 June 2008) ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 3.3.1 fixes a bunch of bugs in 3.3.0, adds support for glibc-2.8 based systems (openSUSE 11, Fedora Core 9), improves the existing glibc-2.7 support, and adds support for the SSSE3 (Core 2) instruction set. 3.3.1 will likely be the last release that supports some very old systems. In particular, the next major release, 3.4.0, will drop support for the old LinuxThreads threading library, and for gcc versions prior to 3.0. The fixed bugs are as follows. Note that "n-i-bz" stands for "not in bugzilla" -- that is, a bug that was reported to us but never got a bugzilla entry. We encourage you to file bugs in bugzilla (http://bugs.kde.org/enter_valgrind_bug.cgi) rather than mailing the developers (or mailing lists) directly -- bugs that are not entered into bugzilla tend to get forgotten about or ignored. n-i-bz Massif segfaults at exit n-i-bz Memcheck asserts on Altivec code n-i-bz fix sizeof bug in Helgrind n-i-bz check fd on sys_llseek n-i-bz update syscall lists to kernel 2.6.23.1 n-i-bz support sys_sync_file_range n-i-bz handle sys_sysinfo, sys_getresuid, sys_getresgid on ppc64-linux n-i-bz intercept memcpy in 64-bit ld.so's n-i-bz Fix wrappers for sys_{futimesat,utimensat} n-i-bz Minor false-error avoidance fixes for Memcheck n-i-bz libmpiwrap.c: add a wrapper for MPI_Waitany n-i-bz helgrind support for glibc-2.8 n-i-bz partial fix for mc_leakcheck.c:698 assert: 'lc_shadows[i]->data + lc_shadows[i] ... n-i-bz Massif/Cachegrind output corruption when programs fork n-i-bz register allocator fix: handle spill stores correctly n-i-bz add support for PA6T PowerPC CPUs 126389 vex x86->IR: 0xF 0xAE (FXRSTOR) 158525 ==126389 152818 vex x86->IR: 0xF3 0xAC (repz lodsb) 153196 vex x86->IR: 0xF2 0xA6 (repnz cmpsb) 155011 vex x86->IR: 0xCF (iret) 155091 Warning [...] unhandled DW_OP_ opcode 0x23 156960 ==155901 155528 support Core2/SSSE3 insns on x86/amd64 155929 ms_print fails on massif outputs containing long lines 157665 valgrind fails on shmdt(0) after shmat to 0 157748 support x86 PUSHFW/POPFW 158212 helgrind: handle pthread_rwlock_try{rd,wr}lock. 158425 sys_poll incorrectly emulated when RES==0 158744 vex amd64->IR: 0xF0 0x41 0xF 0xC0 (xaddb) 160907 Support for a couple of recent Linux syscalls 161285 Patch -- support for eventfd() syscall 161378 illegal opcode in debug libm (FUCOMPP) 160136 ==161378 161487 number of suppressions files is limited to 10 162386 ms_print typo in milliseconds time unit for massif 161036 exp-drd: client allocated memory was never freed 162663 signalfd_wrapper fails on 64bit linux (3.3.1.RC1: 2 June 2008, vex r1854, valgrind r8169). |
|
From: Julian S. <js...@ac...> - 2008-06-02 09:07:26
|
On Wednesday 28 May 2008 08:10, Bart Van Assche wrote: > On Wed, May 28, 2008 at 1:22 AM, Julian Seward <js...@ac...> wrote: > > lwarx and stwcx. are used together to create such sequences, but > > there is no real constraint on what insns go between them, either > > statically or dynamically. So there is no easy way, at JIT time, > > to guarantee to observe that a given sequence represents an > > atomic test-and-set (or whatever). At a guess I'd say it's > > undecideable in general. That said, it is probably possible to > > do better than at present by using some kind of idiom recognition > > scheme, or IR analysis. But neither of those will be simple or > > completely robust. > > I am familiar with how lwarx and stwcx work. But as far as I > understand the VEX source code currently no information is passed by > VEX to Valgrind tools about the bus snoop mechanism used by lwarx and > stwcx. Do you think it would be a good idea to modify VEX such that it > passes the following information to tools: > * For lwarx instructions, the address being watched on the bus. > * For stwcx instructions, the address for which the bus has been > watched and whether or not another CPU has accessed that address since > the bus watch started. It would be easy enough to modify vex to pass supply the relevant info, for example * for load instructions, whether they are a normal load or a lwarx * for store instructions, the same plus the tool gets to see all loads and stores anyway, if it wants. It seems to me that the above is not the real problem. The real problem is, even if you have all that information available, how can it be used to infer which pieces of memory are being atomically modified? J |
|
From: <sv...@va...> - 2008-06-02 07:14:25
|
Author: bart
Date: 2008-06-02 08:14:20 +0100 (Mon, 02 Jun 2008)
New Revision: 8172
Log:
Modified TLS-test slightly: the program checking for TLS support is now compiled, linked and run when compiling natively and compiled and linked only when cross-compiling. Before it was compiled and linked only, both for native and cross-compilation.
Modified:
trunk/configure.in
Modified: trunk/configure.in
===================================================================
--- trunk/configure.in 2008-06-01 22:49:25 UTC (rev 8171)
+++ trunk/configure.in 2008-06-02 07:14:20 UTC (rev 8172)
@@ -1149,13 +1149,27 @@
# Check for TLS support in the compiler and linker
+if test "x${cross_compiling}" = "xno"; then
+# Native compilation: check whether running a program using TLS succeeds.
+# Linking only is not sufficient -- e.g. on Red Hat 7.3 linking TLS programs
+# succeeds but running programs using TLS fails.
AC_CACHE_CHECK([for TLS support], vg_cv_tls,
[AC_ARG_ENABLE(tls, [ --enable-tls platform supports TLS],
[vg_cv_tls=$enableval],
+ [AC_RUN_IFELSE([AC_LANG_PROGRAM([[static __thread int foo;]],
+ [[return foo;]])],
+ [vg_cv_tls=yes],
+ [vg_cv_tls=no])])])
+else
+# Cross-compiling: check whether linking a program using TLS succeeds.
+AC_CACHE_CHECK([for TLS support], vg_cv_tls,
+ [AC_ARG_ENABLE(tls, [ --enable-tls platform supports TLS],
+ [vg_cv_tls=$enableval],
[AC_LINK_IFELSE([AC_LANG_PROGRAM([[static __thread int foo;]],
[[return foo;]])],
[vg_cv_tls=yes],
[vg_cv_tls=no])])])
+fi
if test "$vg_cv_tls" = yes; then
AC_DEFINE([HAVE_TLS], 1, [can use __thread to define thread-local variables])
|
|
From: Tom H. <th...@cy...> - 2008-06-02 02:56:07
|
Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-06-02 03:20:06 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 437 tests, 7 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-06-02 02:43:15
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-06-02 03:25:03 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 435 tests, 7 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap2 (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2008-06-02 02:38:35
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-06-02 03:10:06 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 431 tests, 7 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) none/tests/pth_cvsimple (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 431 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) none/tests/blockfault (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Mon Jun 2 03:25:12 2008 --- new.short Mon Jun 2 03:38:40 2008 *************** *** 8,10 **** ! == 431 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 431 tests, 7 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) *************** *** 14,15 **** --- 14,16 ---- none/tests/mremap2 (stdout) + none/tests/pth_cvsimple (stdout) helgrind/tests/tc18_semabuse (stderr) |