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

[Eli Zaretskii]

> Date: Wed, 31 Dec 2008 14:00:33 +0100
> From: "Juanma Barranquero" <address@hidden>
> 
> Building Emacs on Windows with the following compiler
> 
>   gcc (GCC) 4.3.0 20080305 (alpha-testing) mingw-20080502
> 
> and optimizations on, Emacs returns 0 seconds for all time values
> computed in w32.c:process_times:
> 
> ELISP> (mapcar (lambda (p) (assq 'start (system-process-attributes
> p))) (list-system-processes))
> (nil
>  (start 0 0 0)
>  (start 0 0 484375)
>  (start 0 0 484375)
>  (start 0 0 921875)
>  ;;; etc
> 
> and the same goes for 'utime, 'ctime and 'etime.
> 
> Could someone please try with another version of MinGW GCC?

It works for me with GCC 3.4.2 and MinGW 3.14:

 (mapcar (lambda (p) (assq 'start (system-process-attributes p))) 
(list-system-processes))

  => (nil (start 0 0 0) (start 18778 61572 203125) (start 18778 61575 984375) 
(start 18778 61576 671875) (start 18778 61578 640625) (start 18778 61578 
687500) (start 18778 61580 390625) (start 18778 61580 953125) (start 18778 
61581 203125) (start 18778 61581 296875) (start 18778 61581 906250) (start 
18778 61582 140625) (start 18778 61584 875000) (start 18778 61585 31250) (start 
18778 61591 781250) (start 18778 61592 406250) (start 18778 61592 562500) 
(start 18778 61592 953125) (start 18778 61593 78125) (start 18778 61593 234375) 
(start 18778 61593 359375) (start 18778 61596 828125) (start 18778 61596 
875000) (start 18778 61604 93750) (start 18778 61699 156250) (start 18778 61702 
15625) (start 18778 61702 250000) (start 18778 61702 812500) (start 18778 61704 
390625) (start 18778 61704 984375) (start 18778 61705 921875) (start 18778 
61709 828125) (start 18778 61712 828125) (start 18778 61713 62500) (start 18778 
61714 328125) (start 18778 61715 671875) (start 18778 61715 984375) (start 

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?  Or
maybe it's convert_time_raw that fails? do other callers of
convert_time_raw still work?