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
|
2
(5) |
3
(2) |
4
|
5
|
6
|
7
(1) |
|
8
(2) |
9
|
10
(3) |
11
(1) |
12
(7) |
13
|
14
(1) |
|
15
|
16
|
17
|
18
(1) |
19
|
20
|
21
|
|
22
|
23
(1) |
24
|
25
|
26
|
27
|
28
|
|
29
(1) |
30
|
|
|
|
|
|
|
From: Robert W. <rj...@du...> - 2003-06-12 21:00:12
|
> Whoops, I accidentally made a partial commit. It's fixed now. SIOCOUTQ > is defined in linux/sockios.h, on my machine (and hopefully yours...). That did the trick. Ta very much. Regards, Robert. |
|
From: Nicholas N. <nj...@ca...> - 2003-06-12 20:44:55
|
On 12 Jun 2003, Robert Walsh wrote: > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O -fomit-frame-pointer -mpreferred-stack-boundary=2 -g -mpreferred-stack-boundary=2 -c `test -f 'vg_syscalls.c' || echo > './'`vg_syscalls.c > vg_syscalls.c: In function `vgPlain_perform_assumed_nonblocking_syscall': > vg_syscalls.c:2526: `SIOCOUTQ' undeclared (first use in this function) > vg_syscalls.c:2526: (Each undeclared identifier is reported only once > vg_syscalls.c:2526: for each function it appears in.) > make[1]: *** [vg_syscalls.o] Error 1 > > #ifdef'ing out that ioctl fixes the build. Where's SIOCOUTQ defined? > I couldn't find it anywhere in my RH9 distribution. Whoops, I accidentally made a partial commit. It's fixed now. SIOCOUTQ is defined in linux/sockios.h, on my machine (and hopefully yours...). N |
|
From: Robert W. <rj...@du...> - 2003-06-12 20:33:50
|
On RH9, I get this error: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O -fomit-frame-pointer -mpreferred-stack-boundary=2 -g -mpreferred-stack-boundary=2 -c `test -f 'vg_syscalls.c' || echo './'`vg_syscalls.c vg_syscalls.c: In function `vgPlain_perform_assumed_nonblocking_syscall': vg_syscalls.c:2526: `SIOCOUTQ' undeclared (first use in this function) vg_syscalls.c:2526: (Each undeclared identifier is reported only once vg_syscalls.c:2526: for each function it appears in.) make[1]: *** [vg_syscalls.o] Error 1 #ifdef'ing out that ioctl fixes the build. Where's SIOCOUTQ defined? I couldn't find it anywhere in my RH9 distribution. Regards, Robert. |
|
From: Robert W. <rj...@ke...> - 2003-06-12 19:05:51
|
On RH9, I get this error: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include -DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O -fomit-frame-pointer -mpreferred-stack-boundary=2 -g -mpreferred-stack-boundary=2 -c `test -f 'vg_syscalls.c' || echo './'`vg_syscalls.c vg_syscalls.c: In function `vgPlain_perform_assumed_nonblocking_syscall': vg_syscalls.c:2526: `SIOCOUTQ' undeclared (first use in this function) vg_syscalls.c:2526: (Each undeclared identifier is reported only once vg_syscalls.c:2526: for each function it appears in.) make[1]: *** [vg_syscalls.o] Error 1 #ifdef'ing out that ioctl fixes the build. Where's SIOCOUTQ defined? I couldn't find it anywhere in my RH9 distribution. Regards, Robert. |
|
From: Jeremy D. <jer...@fr...> - 2003-06-12 08:23:51
|
Nicholas Nethercote wrote:
> Just to clarify something: I said in another thread that Valgrind only
> complains if an uninitialised variable is used in a condition, as a system
> call arg, or as a pointer. That's not true for uninitialised values in
> floating point registers; they're always checked.
I know of that: it is written in the documentation (3.5.2).
> The reason is that
> uninitialised non-FP data is often copied around in memory and through the
> general purpose regs, but in practice FP data is hardly ever copied around
> uninitialised via the FP registers.
I disagree: this is exactly what happens in my example (which comes out
of a real program)
> And because of the way FP
> instructions are handled, it's easier to check FP values as soon as
> they're used. And if you copied an uninitialised integer through a FP
> register, Valgrind would complain. That explains the behaviour you get in
> your test program.
>
All I say is that this behavior could be improved (*I* did not copy an
uninitialised integer through a FP register, *the compiler* did --
moreover, it's actually a FP value), by making it the same as for
integer instructions ("delayed" warning).
-J-
|
|
From: Nicholas N. <nj...@ca...> - 2003-06-12 07:32:00
|
On Wed, 11 Jun 2003, Julian Seward wrote: > > > Lines 39-42 are the interesting ones: in that case, the compiler found > > it better to copy Z data by the exclusive use of integer > > instructions. Hence valgrind's silence. > > > > This is, IMHO, a very undesirable behavior discontinuity. Wouldn't be > > better to have valgrind complain about uninitialized floating values > > in exactly the same way as with integer ones ? > > Your observations are completely correct. But the problem is, how > can we know merely by looking at the object code, whether what is > being moved is (in some high level language) an int or a float? > I don't know of any general solution to this. Just to clarify something: I said in another thread that Valgrind only complains if an uninitialised variable is used in a condition, as a system call arg, or as a pointer. That's not true for uninitialised values in floating point registers; they're always checked. The reason is that uninitialised non-FP data is often copied around in memory and through the general purpose regs, but in practice FP data is hardly ever copied around uninitialised via the FP registers. And because of the way FP instructions are handled, it's easier to check FP values as soon as they're used. And if you copied an uninitialised integer through a FP register, Valgrind would complain. That explains the behaviour you get in your test program. N |
|
From: Jeremy D. <jer...@fr...> - 2003-06-12 07:09:50
|
Julian Seward wrote: >>This is, IMHO, a very undesirable behavior discontinuity. Wouldn't be >>better to have valgrind complain about uninitialized floating values >>in exactly the same way as with integer ones ? > > > Your observations are completely correct. But the problem is, how > can we know merely by looking at the object code, whether what is > being moved is (in some high level language) an int or a float? > I don't know of any general solution to this. > I don't know of any either ;-) Let's make it clear: my suggestion is to add the same instrumentation to *assembly* floating instructions (flds, fstps, ...) as the one already in use for integer instructions. In my example, I would not expect vg to issue a message at copy construction of y2; I'd like an alert to be triggered when y2's use gets problematic (i.e. never, here). This could be achieved through the same "delay" scheme used for integer instructions (i.e. when control flow relies on it or something). -J- |