http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49428
Summary: Wrong FP calculation that yields 0.0.
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ecologicyb...@gmail.com
Created attachment 24539
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24539
for reproducing the bug.
There's a bug that it sometimes returns 0.0000 instead of 0.6000 ns
when the cpu freq. is definitively around 1.6666 GHz
gcc test.c ; ./a.out [ gcc (Debian 4.5.2-8) 4.5.2 ]
double nanoseconds_by_cpu_cycle(uint64_t frequency) {
double ns;
ns = 1000000000.0L / ((double)frequency);
return(ns);
}
Here the objdump.
08048547 <nanoseconds_by_cpu_cycle>:
8048547: 55 push %ebp
8048548: 89 e5 mov %esp,%ebp
804854a: 83 ec 20 sub $0x20,%esp
804854d: 8b 45 08 mov 0x8(%ebp),%eax
8048550: 89 45 e8 mov %eax,-0x18(%ebp)
8048553: 8b 45 0c mov 0xc(%ebp),%eax
8048556: 89 45 ec mov %eax,-0x14(%ebp)
8048559: df 6d e8 fildll -0x18(%ebp)
804855c: 83 7d ec 00 cmpl $0x0,-0x14(%ebp)
8048560: 79 08 jns 804856a
<nanoseconds_by_cpu_cycle+0x23>
8048562: db 2d 50 88 04 08 fldt 0x8048850
8048568: de c1 faddp %st,%st(1)
804856a: dd 5d e0 fstpl -0x20(%ebp)
804856d: dd 45 e0 fldl -0x20(%ebp)
8048570: db 2d 60 88 04 08 fldt 0x8048860
8048576: de f1 fdivp %st,%st(1)
8048578: dd 5d f8 fstpl -0x8(%ebp)
804857b: dd 45 f8 fldl -0x8(%ebp)
804857e: c9 leave
804857f: c3 ret
I see that FP generation code is buggy, i don't see why there's a
conditional branch jns although there's a risk of division by
zero that never happened.
1000000000.0L / ((double)1666656800LL aprox.) did give me 0.0 wrongly.
Could be a side-effect of NaN, +Infty or -Infty?
