This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Latest 64 bit test stuff on sourceware
On Feb 16 22:47, Ken Brown wrote:
> On 2/16/2013 5:17 PM, Peter Rosin wrote:
> >3. The config.status scripts generated by the configure scrips
> >I have tested are not working (all Makefiles end up empty), but
> >I suspect that's some issue between autoconf and dash. So far it
> >has worked to run ./config.status from plain old non-64-cygwin
> >between configure and make.
>
> I made a first attempt to build emacs. I had the same problem as
> Peter with all Makefiles being empty. In addition, the configure
> test for mktime (attached) fails; CPU usage spins up to 25% (one
> core), and the program has to be killed from the Task Manager.
>
> Ken
Oh well. I don't know how to "fix" this, other than by ripping out
the entire localtime/mktime implementation and replacing it with
something new.
The reason here is the testcase itself:
> static int
> mktime_test (time_t now)
> {
> return (mktime_test1 (now)
> && mktime_test1 ((time_t) (time_t_max - now))
> && mktime_test1 ((time_t) (time_t_min + now)));
> }
> [...]
> int
> main ()
> {
> int result = 0;
> time_t t, delta;
> int i, j;
> int time_t_signed_magnitude = (time_t) ~ (time_t) 0 < (time_t) -1;
> int time_t_signed = ! ((time_t) 0 < (time_t) -1);
>
> /* This test makes some buggy mktime implementations loop.
> Give up after 60 seconds; a mktime slower than that
> isn't worth using anyway. */
> alarm (60);
>
> time_t_max = (! time_t_signed
> ? (time_t) -1
> : ((((time_t) 1 << (sizeof (time_t) * CHAR_BIT - 2)) - 1)
> * 2 + 1));
> time_t_min = (! time_t_signed
> ? (time_t) 0
> : time_t_signed_magnitude
> ? ~ (time_t) 0
> : ~ time_t_max);
> [...]
So what it does is calling localtime with a time_t value set to
time_t_max. That's 0x7fffffff on i686, which manages to do the job in
less than 60 seconds. On 64 bit, time_t_max is 0x7fffffffffffffff.
That's roughly 2^32 times bigger than the 32 bit value, but the 64 bit
CPU isn't 2^32 times faster, unfortunately.
The problem in Cygwin's localtime is the loop in timesub. It uses a
loop to subtract days-per-year from the incoming value. That can take
quite some time...
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat