Latest 64 bit test stuff on sourceware

[Ken Brown]

On 2/18/2013 7:12 AM, Corinna Vinschen wrote:
> 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.

OK.  But is there something else going on in addition to that?  In my 
tests, the program doesn't terminate after 60 seconds.  Moreover, it 
doesn't respond to `kill -9'; I have to kill it from the Task Manager.

Ken