|
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: 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: 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: 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: 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: 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: 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
|