|
From: ragnar s. <rag...@po...> - 2003-07-10 14:32:28
|
Thanks for the help, I've upgraded to 1.9.6,
but valgrind still gives the same result.
Considering the following code:
int
main (int argc, char **argv)
{
float e;
e = 0;
e = e * (float)0.7;
return 0;
}
Gcc treats:
float e;
e = e * 0.7;
differently from :
e = e * (float)0.7;
As is shown in this assembler output,
when toggling first with the (float) cast
then without:
---------------
.section .rodata
.align 4
.LC0:
.long 0x3f333333
.text
.align 4
<snip>
flds .LC0
fmulp %st,%st(1)
--------------
.section .rodata
.align 8
.LC0:
.long 0x66666666,0x3fe66666
.text
.align 4
<snip>
fldl .LC0
fmulp %st,%st(1)
-------
My guess is the first assembler output
is using single-precision, and the second
defaults to double ?
So the func.c/prog.c should use double-precision correctly I assume ?
Still, is there a error in the func.c/prog.c program, that valgrind thinks ?
thanks
Ragnar
___________________________________________________
Who invented the Centigrade scale of temperature?
Find out at postmaster.co.uk
http://www.postmaster.co.uk/cgi-bin/meme/quiz.pl?id=196
|
|
From: Paul H. <pa...@ha...> - 2003-07-10 16:42:03
|
On Thu, 10 Jul 2003, ragnar sjoberg wrote:
> Thanks for the help, I've upgraded to 1.9.6,
> but valgrind still gives the same result.
It looks like a gcc problem, not a valgrind problem.
I added '#include <stdlib.h>' to prog.c to get the definition for exit().
exit() isn't defined in stdio.h anymore. How old is your copy of gcc?
Here is your original func.c:
#include <stdio.h>
void
func_one (int len)
{
int c;
float e;
e = 0;
c = 0;
while(c < len)
{
e = e * 0.7;
c++;
}
}
"e" isn't used for anything except calculating "e". In your first example
you compiled with -O3. The compiler should have optimized away all of the
references to "e" and 0.7.
I looked at the assembler output after typing:
gcc -S -O3 func.c
and they were indeed gone. (Still room for improvement, the loop was still
there.)
It looks like your version of gcc only removed some of the dead code.
Leaving some broken dead code. Valgrind detected that the dead code was
broken.
> Still, is there a error in the func.c/prog.c program, that valgrind thinks ?
I tried a couple different versions of gcc and valgrind didn't see any
problems when I compiled them.
The versions I tried were:
gcc version 3.2.3 20030331 (Debian prerelease)
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
Type
gcc -v
to see what compiler you are using.
--
Paul Haas pa...@ha...
|
|
From: Dirk M. <dm...@gm...> - 2003-07-10 17:59:44
|
On Don, 10 Jul 2003, ragnar sjoberg wrote: > .LC0: > .long 0x3f333333 > .text > .align 4 > <snip> > flds .LC0 > .long 0x66666666,0x3fe66666 > .text > .align 4 > <snip> > fldl .LC0 > My guess is the first assembler output > is using single-precision, and the second > defaults to double ? Yes, see flds vs fldl. So the assembly is correct, valgrinds warning is wrong as far as I can see. However, I cannot reproduce it with the current CVS HEAD version. perhaps it depends on the compiler / glibc ? which versions do you use? -- Dirk |
|
From: Nicholas N. <nj...@ca...> - 2003-07-20 15:16:03
|
On Thu, 10 Jul 2003, ragnar sjoberg wrote:
> Thanks for the help, I've upgraded to 1.9.6,
> but valgrind still gives the same result.
I tried your program with the current CVS head, and I get no errors.
Maybe it depends which version of gcc you use.
Can you reduce your program to the smallest two versions that show the
different behaviours, and then post the (complete) assembly code for them?
That will give us a better chance of working out what the problem is.
N
>
> Considering the following code:
> int
> main (int argc, char **argv)
> {
> float e;
>
> e = 0;
> e = e * (float)0.7;
>
> return 0;
> }
>
>
> Gcc treats:
> float e;
> e = e * 0.7;
> differently from :
> e = e * (float)0.7;
>
> As is shown in this assembler output,
> when toggling first with the (float) cast
> then without:
> ---------------
> .section .rodata
> .align 4
> .LC0:
> .long 0x3f333333
> .text
> .align 4
> <snip>
> flds .LC0
> fmulp %st,%st(1)
>
> --------------
>
> .section .rodata
> .align 8
> .LC0:
> .long 0x66666666,0x3fe66666
> .text
> .align 4
> <snip>
> fldl .LC0
> fmulp %st,%st(1)
> -------
>
> My guess is the first assembler output
> is using single-precision, and the second
> defaults to double ?
>
> So the func.c/prog.c should use double-precision correctly I assume ?
>
> Still, is there a error in the func.c/prog.c program, that valgrind thinks ?
>
> thanks
> Ragnar
>
>
> ___________________________________________________
> Who invented the Centigrade scale of temperature?
>
> Find out at postmaster.co.uk
>
> http://www.postmaster.co.uk/cgi-bin/meme/quiz.pl?id=196
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Parasoft
> Error proof Web apps, automate testing & more.
> Download & eval WebKing and get a free book.
> www.parasoft.com/bulletproofapps
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
|