You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
1
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Joerg B. <jo...@we...> - 2003-08-01 09:56:06
|
Vincent Penquerc'h wrote:
>>joerg> gcc -S main.c && cat main.s
>
> [...]
>
>> call asinf
>
>
> When optimizing, glibc supplies inline asm implementations of
> some math routines. acosf/asinf may be among these (I'm at work
> with a Windows machine here, so can't check). Try -O2.
>
this is the relevant part of main.c compiled with -O2:
main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
subl $12, %esp
pushl $0x3f000000
call asinf
fstp %st(0)
movl %ebp, %esp
xorl %eax, %eax
popl %ebp
ret
it looks like no further optimization has been inlined.
Joerg
|
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-01 09:49:42
|
> >> Unhandled REPE case [...] > That's what the REPE (0xf3) prefix means, yes, but in this case > it isn't really a REPE prefix at all. The sequence was 0xf3 0x0f which > is an SSE instruction that valgrind 1.9.6 certainly won't handle. Ah, so do you mean f3 means repe, except when followed by 0f (and possibly other bytes) ? That's devious :) I'm glad I only coded a disassembler for 8086 :) Thanks for the correction. -- Vincent Penquerc'h |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-01 09:45:20
|
> joerg> gcc -S main.c && cat main.s [...] > call asinf When optimizing, glibc supplies inline asm implementations of some math routines. acosf/asinf may be among these (I'm at work with a Windows machine here, so can't check). Try -O2. -- Vincent Penquerc'h |
|
From: Nicholas N. <nj...@ca...> - 2003-08-01 09:40:46
|
On Fri, 1 Aug 2003, Tom Hughes wrote: > >> valgrind: the `impossible' happened: > >> Unhandled REPE case > > in this case it isn't really a REPE prefix at all. The sequence was 0xf3 > 0x0f which is an SSE instruction that valgrind 1.9.6 certainly won't > handle. In which case try version 20030725 which does have support for some SSE instructions. N |
|
From: Andreas F. <and...@di...> - 2003-08-01 09:37:29
|
Aha, so Gentoo's libm has SSE stuff included because of my
compilation settings for the OS. That explains the issue.
Thanks for your help everyone.
Regards,
Andreas
-----Original Message-----
From: Tom Hughes
To: val...@li...
Sent: 8/1/2003 11:29 AM
Subject: Re: [Valgrind-users] cosf() and friends
In message <B14C9D7F1977D111AD740060970ACBDA018934A9@warhol>
Vincent Penquerc'h <Vin...@ar...> wrote:
>> valgrind: the `impossible' happened:
>> Unhandled REPE case
>
> This is a x86 prefix which Valgrind simply doesn't support.
> It means "loop next insn". Support for it should be added to
> Valgrind for this insn. This is not a bug, just something
> which was never needed until now.
That's what the REPE (0xf3) prefix means, yes, but in this case
it isn't really a REPE prefix at all. The sequence was 0xf3 0x0f which
is an SSE instruction that valgrind 1.9.6 certainly won't handle.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01
/01
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <th...@cy...> - 2003-08-01 09:30:39
|
In message <B14C9D7F1977D111AD740060970ACBDA018934A9@warhol>
Vincent Penquerc'h <Vin...@ar...> wrote:
>> valgrind: the `impossible' happened:
>> Unhandled REPE case
>
> This is a x86 prefix which Valgrind simply doesn't support.
> It means "loop next insn". Support for it should be added to
> Valgrind for this insn. This is not a bug, just something
> which was never needed until now.
That's what the REPE (0xf3) prefix means, yes, but in this case
it isn't really a REPE prefix at all. The sequence was 0xf3 0x0f which
is an SSE instruction that valgrind 1.9.6 certainly won't handle.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-01 09:16:20
|
> valgrind: the `impossible' happened: > Unhandled REPE case This is a x86 prefix which Valgrind simply doesn't support. It means "loop next insn". Support for it should be added to Valgrind for this insn. This is not a bug, just something which was never needed until now. What you can try is to undefine __OPTIMIZE__ (IIRC, check the exact define in /usr/include/bits/mathinline.h IIRC) before including math.h, that could help if acosf has an asm body which is used when optimizing (as do things like sincos). acosf is kinda slow in the first place, so it might not have much impact do use the slow version. YMMV. -- Vincent Penquerc'h |
|
From: Joerg B. <jo...@we...> - 2003-08-01 09:11:16
|
Andreas Fredriksson wrote:
> Hi Nicholas,
>
> it seems I was a bit quick to type, cosf() actually works,
> what I really meant was acosf():
>
> #include <math.h>
>
> int main(int argc, char** argv)
> {
> float f = asinf(0.5);
> return 0;
> }
>
> gives me:
>
> $ valgrind /tmp/acostest
> ==4163== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
> ==4163== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
> ==4163== Using valgrind-1.9.6, a program instrumentation system for
> x86-linux.
> ==4163== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
> ==4163== Estimated CPU clock rate is 1754 MHz
> ==4163== For more details, rerun with: -v
> ==4163==
> REPE then 0xF
>
> valgrind: the `impossible' happened:
> Unhandled REPE case
> Basic block ctr is approximately 0
>
> sched status:
>
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==4163== at 0x4022D502: __acosf (in /lib/libm-2.3.2.so)
> ==4163== by 0x80483A3: main (in /tmp/acostest)
> ==4163== by 0x402557A6: __libc_start_main (in /lib/libc-2.3.2.so)
> ==4163== by 0x80482F0: (within /tmp/acostest)
>
> Regards,
> Andreas
Andrea,
with my setup, it works:
joerg> gcc main.c -lm
joerg> ./a.out
joerg> gcc main.c -lm && valgrind a.out
==19228== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==19228== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==19228== Using valgrind-20030716, a program supervision framework for
x86-linux .
==19228== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==19228== Estimated CPU clock rate is 2797 MHz
==19228== For more details, rerun with: -v
==19228==
==19228==
==19228== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==19228== malloc/free: in use at exit: 0 bytes in 0 blocks.
==19228== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==19228== For a detailed leak analysis, rerun with: --leak-check=yes
==19228== For counts of detected errors, rerun with: -v
joerg> gcc --version
gcc (GCC) 3.2 (SuSE Linux)
so, maybe a newer valgrind my help you?
if that is not the case, we could compare the assembler code of the
example:
joerg> gcc -S main.c && cat main.s
cat main.s
.file "main.c"
.text
.align 2
.globl main
.type main,@function
main:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
movl $0, %eax
subl %eax, %esp
subl $12, %esp
pushl $0x3f000000
call asinf
addl $16, %esp
fstps -4(%ebp)
movl $0, %eax
leave
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 3.2 (SuSE Linux)"
mybe the difference is in the math-lib?
joerg> ldd a.out
libm.so.6 => /lib/libm.so.6 (0x40022000)
libc.so.6 => /lib/libc.so.6 (0x40045000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
hope that helps
Joerg
|
|
From: Andreas F. <and...@di...> - 2003-08-01 08:30:42
|
Hi Nicholas,
it seems I was a bit quick to type, cosf() actually works,
what I really meant was acosf():
#include <math.h>
int main(int argc, char** argv)
{
float f = asinf(0.5);
return 0;
}
gives me:
$ valgrind /tmp/acostest
==4163== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==4163== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==4163== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.
==4163== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==4163== Estimated CPU clock rate is 1754 MHz
==4163== For more details, rerun with: -v
==4163==
REPE then 0xF
valgrind: the `impossible' happened:
Unhandled REPE case
Basic block ctr is approximately 0
sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==4163== at 0x4022D502: __acosf (in /lib/libm-2.3.2.so)
==4163== by 0x80483A3: main (in /tmp/acostest)
==4163== by 0x402557A6: __libc_start_main (in /lib/libc-2.3.2.so)
==4163== by 0x80482F0: (within /tmp/acostest)
Regards,
Andreas
-----Original Message-----
From: Nicholas Nethercote
To: Andreas Fredriksson
Cc: 'val...@li...'
Sent: 8/1/2003 10:20 AM
Subject: Re: [Valgrind-users] cosf() and friends
On Fri, 1 Aug 2003, Andreas Fredriksson wrote:
> this is my first post here, so first let me say that I'm very
> impressed with valgrind and it's becoming an indispensible tool
> in my toolbox.
Great, thanks :)
> I noticed that the floating-point variations of cos(),
> sin() and friends are not supported by valgrind-1.9.6
> (I'm using gentoo linux 1.4), so I had to whip up a sed
> script to replace these with their double couterparts
> for the valgrind build.
I'm not sure what you mean by "not supported". Does it abort execution?
I'd never heard of these functions, but I just ran this program:
#include <stdio.h>
#include <math.h>
int main(void)
{
float arg = 0.777;
float ans = cosf(arg);
printf("%f\n", ans);
return 0;
}
and it worked fine with the current version (which I think should
operate
the same as 1.9.6 in this case).
Is this what you mean? Can you post a small test program in C or (even
better) assembly code?
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-01 08:20:25
|
On Fri, 1 Aug 2003, Andreas Fredriksson wrote:
> this is my first post here, so first let me say that I'm very
> impressed with valgrind and it's becoming an indispensible tool
> in my toolbox.
Great, thanks :)
> I noticed that the floating-point variations of cos(),
> sin() and friends are not supported by valgrind-1.9.6
> (I'm using gentoo linux 1.4), so I had to whip up a sed
> script to replace these with their double couterparts
> for the valgrind build.
I'm not sure what you mean by "not supported". Does it abort execution?
I'd never heard of these functions, but I just ran this program:
#include <stdio.h>
#include <math.h>
int main(void)
{
float arg = 0.777;
float ans = cosf(arg);
printf("%f\n", ans);
return 0;
}
and it worked fine with the current version (which I think should operate
the same as 1.9.6 in this case).
Is this what you mean? Can you post a small test program in C or (even
better) assembly code?
N
|
|
From: Andreas F. <and...@di...> - 2003-08-01 07:33:13
|
Hi all, this is my first post here, so first let me say that I'm very impressed with valgrind and it's becoming an indispensible tool in my toolbox. I work for DICE and I'm developing the Linux port of our dedicated server for our game Battlefield 1942. My debug executable is about 90 megs in size, and valgrind runs it pretty happily. With the memcheck skin active there's no chance of actually playing on the server, but that's not the point either. :-) I noticed that the floating-point variations of cos(), sin() and friends are not supported by valgrind-1.9.6 (I'm using gentoo linux 1.4), so I had to whip up a sed script to replace these with their double couterparts for the valgrind build. Is this a known issue, or should it be added to the FAQ? I was thinking that this could be because Gentoo optimizes the c library for the CPU (AMD Athlon in my case) which could generate instructions not suitable for valgrind's synthetic CPU. Can anyone comment on this? Regards, Andreas Fredriksson |