[Bug c/49428] New: Wrong FP calculation that yields 0.0.

["ecologicyborg at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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: unassigned@gcc.gnu.org
        ReportedBy: ecologicyborg@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?