Re: Optimized gcc 4.3.0 build on Windows returns 0 secs for all time values of system-process-attributes

[Eli Zaretskii]

> Date: Sat, 3 Jan 2009 03:27:15 +0100
> From: "Juanma Barranquero" <address@hidden>
> Cc: address@hidden
> 
> > Why not? it worked for me, and it still does.
> 
> Manipulating precise quantities through floats seems ugly.

That's what that code did before I wrote system-process-attributes,
and I wanted to reuse existing code.  A `long double' type has 64 bits
of mantissa on an IA-32 machine, so no loss of precision seemed to be
involved.

> > If the suspicion is that long double calculations don't work here, can
> > you please show the disassembly of these source lines, as they are
> > compiled by GCC 4.3.0:
> >
> >> -  tem1 = convert_time_raw (ft_kernel) * 0.1L;
> >> -  stime_usec = fmodl (tem1, 1000000.0L);
> >> -  stime_sec = tem1 * 0.000001L;
> 
> 3792      tem1 = convert_time_raw (ft_kernel) * 0.1L;
> 0x010b6a94 <system_process_attributes+2140>:    mov    -0x6c(%ebp),%eax

Thanks.  This is still not enough info to zero in on the problem (at
least not for me), but I do see that the produced code is very
different from what GCC 3.x produces for me (see below).  (If someone
can spot the crucial differences in the code that could explain why
the results come out as zero, please speak up.)

Could you please show the values of ft_kernel, stime_sec, and
stime_usec after the last of the above 3 lines, namely after

  stime_sec = tem1 * 0.000001L;

?

These variables are all integers, so printf should handle them
correctly (although you will need to use the non-standard %I64d format
specifier for 64-bit values).

By the way, it sounds like, if you use snprintf, you should be able to
have long double values printed correctly as well, because snprintf
comes from libmingwex library, not from MS runtime.

> > Also, which version of the MinGW runtime do you use?
> 
> gcc 4.3.0-20080502-mingw32-alpha
> mingw-runtime 3.15.1
> w32api 3.13

The MinGW runtime version seems to be irrelevant, since the code you
show doesn't call fmodl at all; instead, it does everything inline.

For the record, here is the corresponding code produced by GCC 3.4.2:

3792   tem1 = convert_time_raw (ft_kernel) * 0.1L;
0x0107e8c9 <system_process_attributes+2341>:    mov    -0x8f0(%ebp),%eax
0x0107e8cf <system_process_attributes+2347>:    mov    -0x8ec(%ebp),%edx
0x0107e8d5 <system_process_attributes+2353>:    sub    $0x4,%esp
0x0107e8d8 <system_process_attributes+2356>:    call   0x107c368 
<convert_time_raw>
0x0107e8dd <system_process_attributes+2361>:    fldt   0x12ce760
0x0107e8e3 <system_process_attributes+2367>:    fmulp  %st,%st(1)
0x0107e8e5 <system_process_attributes+2369>:    fstpt  -0x948(%ebp)
3792   stime_usec = fmodl (tem1, 1000000.0L);
0x0107e8eb <system_process_attributes+2375>:    flds   0x12ce76c
0x0107e8f1 <system_process_attributes+2381>:    fstpt  -0x988(%ebp)
0x0107e8f7 <system_process_attributes+2387>:    mov    -0x988(%ebp),%ebx
0x0107e8fd <system_process_attributes+2393>:    mov    -0x984(%ebp),%esi
0x0107e903 <system_process_attributes+2399>:    mov    -0x980(%ebp),%edi
0x0107e909 <system_process_attributes+2405>:    mov    %edi,0x14(%esp)
0x0107e90d <system_process_attributes+2409>:    mov    %ebx,0xc(%esp)
0x0107e911 <system_process_attributes+2413>:    mov    %esi,0x10(%esp)
0x0107e915 <system_process_attributes+2417>:    fldt   -0x948(%ebp)
0x0107e91b <system_process_attributes+2423>:    fstpt  (%esp)
0x0107e91e <system_process_attributes+2426>:    call   0x1178ba0 <fmodl>
0x0107e923 <system_process_attributes+2431>:    fldt   0x12ce770
3794   stime_sec = tem1 * 0.000001L;
0x0107e929 <system_process_attributes+2437>:    fxch   %st(1)
0x0107e92b <system_process_attributes+2439>:    fnstcw -0x90a(%ebp)
0x0107e931 <system_process_attributes+2445>:    movzwl -0x90a(%ebp),%eax
0x0107e938 <system_process_attributes+2452>:    mov    $0xc,%ah
0x0107e93a <system_process_attributes+2454>:    mov    %ax,-0x90c(%ebp)
0x0107e941 <system_process_attributes+2461>:    fldcw  -0x90c(%ebp)
0x0107e947 <system_process_attributes+2467>:    fistpl -0x910(%ebp)
0x0107e94d <system_process_attributes+2473>:    fldcw  -0x90a(%ebp)
0x0107e953 <system_process_attributes+2479>:    fldt   -0x948(%ebp)
0x0107e959 <system_process_attributes+2485>:    fmulp  %st,%st(1)
0x0107e95b <system_process_attributes+2487>:    mov    -0x910(%ebp),%edx
0x0107e961 <system_process_attributes+2493>:    fldcw  -0x90c(%ebp)
0x0107e967 <system_process_attributes+2499>:    fistpl -0x910(%ebp)

And the code produced for convert_time_raw (which is inlined by GCC
4.3.0) is this:

2748    return
          (long double) ft.dwHighDateTime
          * 4096.0L * 1024.0L * 1024.0L + ft.dwLowDateTime;
0x0107c368 <convert_time_raw+0>:        push   %ebp
0x0107c369 <convert_time_raw+1>:        flds   0x12ce424
0x0107c36f <convert_time_raw+7>:        mov    %esp,%ebp
0x0107c371 <convert_time_raw+9>:        push   %ebx
0x0107c372 <convert_time_raw+10>:       xor    %ebx,%ebx
0x0107c374 <convert_time_raw+12>:       push   %ebx
0x0107c375 <convert_time_raw+13>:       push   %edx
0x0107c376 <convert_time_raw+14>:       xor    %edx,%edx
0x0107c378 <convert_time_raw+16>:       fildll (%esp)
0x0107c37b <convert_time_raw+19>:       add    $0x8,%esp
0x0107c37e <convert_time_raw+22>:       push   %edx
0x0107c37f <convert_time_raw+23>:       fmuls  0x12ce420
0x0107c385 <convert_time_raw+29>:       fmul   %st(1),%st
0x0107c387 <convert_time_raw+31>:       push   %eax
0x0107c388 <convert_time_raw+32>:       fmulp  %st,%st(1)
0x0107c38a <convert_time_raw+34>:       fildll (%esp)
0x0107c38d <convert_time_raw+37>:       add    $0x8,%esp
0x0107c390 <convert_time_raw+40>:       pop    %ebx
0x0107c391 <convert_time_raw+41>:       faddp  %st,%st(1)
0x0107c393 <convert_time_raw+43>:       pop    %ebp
0x0107c394 <convert_time_raw+44>:       ret