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
(6) |
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: Melchior F. <mf...@kd...> - 2003-08-04 12:41:24
|
In valgrind from CVS/HEAD of today, I get several error messages
like this:
==28293== Mismatched free() / delete / delete []
==28293== at 0x2AAD3C81: __builtin_delete (vg_replace_malloc.c:233)
==28293== by 0x2AAD3C9F: operator delete(void*) (vg_replace_malloc.c:242)
==28293== by 0x83681D3: SkyArchive::_Load(_IO_FILE*) (SkyArchive.cpp:1217)
[...]
==28293== Address 0x52AFACF4 is 0 bytes inside a block of size 27 alloc'd
==28293== at 0x2AAD3B27: __builtin_vec_new (vg_replace_malloc.c:197)
==28293== by 0x2AAD3B7E: operator new[](unsigned) (vg_replace_malloc.c:210)
==28293== by 0x8368165: SkyArchive::_Load(_IO_FILE*) (SkyArchive.cpp:1209)
The concerned code in this case is (without the line numbers):
1209: void* pData = new unsigned char[embeddedItem.iDataSize];
...
1217: delete[] pData;
If I replace the silly "void *" by "unsigned char" then the mismatch
is not reported. (This isn't my code!) The new and delete are used
correctly, only the allocated memory is assigned to a void *. Does
this break the necessary information for gcc to use delete correctly?
Shouldn't the compiler know better, or is it a valgrind problem?
m.
Linux 2.4.20, i386
gcc 3.3pre (SuSE)
libc 2.3.2
|
|
From: Joerg B. <jo...@we...> - 2003-08-04 07:07:29
|
Bor...@pd... wrote: > Hi, > > If I wan't to start one of my Applications I get the > following bug: > > relocation error: /lib/librt.so.1: symbol > __pthread_clock_settime, version GLIBC_PRIVATE not > defined in file libpthread.so.0 with link time reference > Hi Borg, this is answered in the FAQ, please take a look at Q13 at: http://developer.kde.org/~sewardj/docs-1.9.5/FAQ.txt hope this helps Joerg |
|
From: <Bor...@pd...> - 2003-08-04 06:42:33
|
Hi, If I wan't to start one of my Applications I get the following bug: relocation error: /lib/librt.so.1: symbol __pthread_clock_settime, version GLIBC_PRIVATE not defined in file libpthread.so.0 with link time reference By the way with version 1.0.4 If have not this error... and If I use the libpthread.so of this version with the actual, my programs are running again. with that I get Occasionaly following error: after failed assertion `0' --28467-- discarding signal 6 for thread 100 because handler missing Sincerely Borg Enders |
|
From: <jhr...@t-...> - 2003-08-03 21:01:44
|
----- Original Message -----
From: "Nicholas Nethercote" <nj...@ca...>
To: "Sebastian Kaliszewski" <sk@z.pl>
Cc: <val...@li...>
Sent: Sunday, August 03, 2003 9:53 PM
Subject: Re: [Valgrind-users] Regression w.r.t. 1.0.3?
> On Sun, 3 Aug 2003, Sebastian Kaliszewski wrote:
>
> > Wouldn't be that a good idea to allow for command line switch to turn
on/off
> > particular CPUID flags?
>
> Er, probably.
That would be great.
> In the meantime, you can workaround it by copying the old implementation
> of CPUID into the new version of Valgrind and recompiling (from
> vg_helpers.S in 1.0.3 --> coregrind/vg_helpers.S in the latest version,
> IIRC).
Tom Hughes sent the correct patch already:
--- vg_helpers.S.orig 2003-06-23 08:10:59.000000000 +0100
+++ vg_helpers.S 2003-08-03 16:33:48.000000000 +0100
@@ -135,12 +135,20 @@
pushl %edx
movl 32(%esp), %eax
+ cmpl $1, %eax
+ je cpuid_nosse
+
cmpl $0x80000001, %eax
je cpuid_no3dnow
cpuid
jmp cpuid__99
+cpuid_nosse:
+ cpuid
+ andl $0xf9ffffff, %edx
+ jmp cpuid__99
+
cpuid_no3dnow:
cpuid
Thanks,
Joerg
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-03 19:53:04
|
On Sun, 3 Aug 2003, Sebastian Kaliszewski wrote: > Wouldn't be that a good idea to allow for command line switch to turn on/off > particular CPUID flags? Er, probably. In the meantime, you can workaround it by copying the old implementation of CPUID into the new version of Valgrind and recompiling (from vg_helpers.S in 1.0.3 --> coregrind/vg_helpers.S in the latest version, IIRC). N |
|
From: Sebastian K.
|
Dnia nie 3. sierpie=F1 2003 15:58, Tom Hughes napisa=B3: > That looks like an SSE instruction to me, presumably one that Julian > hasn't added support for yet. > > Presumably your program using CPUID to check for SSE support before > trying to use SSE instructions, which would be fine in 1.0.3 where > the CPUID would not have indicated SSE support when running under > valgrind. > > Because CPUID now reports SSE support if your underlying CPU has it > your code will try and se it and then fail because the valrind support > for SSE is not complete yet. Wouldn't be that a good idea to allow for command line switch to turn on/= off=20 particular CPUID flags? This would allow not only to work around missing = SSE=20 instructions, but also allow to effectively check/debug executables with=20 variant code depending on presence of various CPU features (some performa= nce=20 oriented apps do that; also ICC above 6.0 or 7.0 does that stuff=20 automatically). rgds Sebastian |
|
From: Tom H. <th...@cy...> - 2003-08-03 13:59:19
|
In message <001801c359c0$d1a748a0$010...@ms...>
jhr...@t-... (Joerg Walter) wrote:
> I've just upgraded from 1.0.3 to valgrind-20030725. The new valgrind is
> failing for one of my programs (compiled with ICC 7.1) complaining
[ snipped]
> disInstr: unhandled instruction bytes: 0xF3 0xF 0x7E 0x44
That looks like an SSE instruction to me, presumably one that Julian
hasn't added support for yet.
Presumably your program using CPUID to check for SSE support before
trying to use SSE instructions, which would be fine in 1.0.3 where
the CPUID would not have indicated SSE support when running under
valgrind.
Because CPUID now reports SSE support if your underlying CPU has it
your code will try and se it and then fail because the valrind support
for SSE is not complete yet.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: <jhr...@t-...> - 2003-08-03 13:21:14
|
Hi all, first of all thanks for giving us such a great tool. I've just upgraded from 1.0.3 to valgrind-20030725. The new valgrind is failing for one of my programs (compiled with ICC 7.1) complaining ==12750== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==12750== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==12750== Using valgrind-20030725, a program supervision framework for x86-linux. ==12750== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==12750== Estimated CPU clock rate is 1714 MHz ==12750== For more details, rerun with: -v ==12750== test_vector [snip] disInstr: unhandled instruction bytes: 0xF3 0xF 0x7E 0x44 ==12750== Use of uninitialised value of size 4 ==12750== at 0x8050E00: has_osfxsr_set (in /usr/local/lib/boost_dev/boost/libs/numeric/ublas/test1/bin/test1/intel-linu x/debug/runtime-link-dynamic/test1) ==12750== ==12750== Jump to the invalid address stated on the next line ==12750== at 0x0: ??? ==12750== Address 0x0 is not stack'd, malloc'd or free'd whereas the old one reports (for the same image) ==12334== valgrind-1.0.3, a memory error detector for x86 GNU/Linux. ==12334== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==12334== Estimated CPU clock rate is 1719 MHz ==12334== For more details, rerun with: -v ==12334== test_vector [snip] ==12334== ==12334== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) ==12334== malloc/free: in use at exit: 300 bytes in 21 blocks. ==12334== malloc/free: 281 allocs, 260 frees, 6272 bytes allocated. ==12334== For a detailed leak analysis, rerun with: --leak-check=yes ==12334== For counts of detected errors, rerun with: -v Is this a known problem? Thanks, Joerg |
|
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 |