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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 1 Jan 2009 05:38:36 +0100
> From: "Juanma Barranquero" <lekktu@gmail.com>
> Cc: emacs-devel@gnu.org
> 
> On Wed, Dec 31, 2008 at 20:12, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > It works for me with GCC 3.4.2 and MinGW 3.14:
> 
> Optimized or unoptimized build?

Optimized.  I used the default switches that nt/gmake.defs sets.

> > Could you please step into process_times and ltime (or add printf's if
> > stepping doesn't work), and see what is going wrong and where?
> 
> Stepping isn't much helpful because most variables are optimized away.
> 
> As for printf, I'm not sure what's wrong, but
> 
>     long double x = 3.5;
>     printf ("f = %Lf\n", x);
>     printf ("g = %Lg\n", x);
> 
>   =>
> 
> f = -26815615859885194000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000.000000
> g = -2.68156e+154
> 
> (Not just with gcc 4.3.0, I get the same result with 3.4.5.)
> 
> Am I missing something obvious?

Looks like Microsoft's runtime does not support the GCC 80-bit long
double, it thinks that long double is the same as double, a 64-bit FP
number.

> I tried rewriting w32.c:process_time to do time computations by using
> ULARGE_INTEGER (see attached patch), as the Platform SDK recommends,
> and it works fine. Why it is implemented with long doubles?

Why not? it worked for me, and it still does.

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;

I'd like to compare them with what GCC 3.4.2 produces.  Thanks.

Also, which version of the MinGW runtime do you use?