Bug 23836

Summary: time/tst-mktime2 test failure on Arm (32-bit)
Product: glibc Reporter: Florian Weimer <fweimer>
Component: timeAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal Flags: fweimer: security-
Priority: P2    
Version: 2.29   
Target Milestone: 2.29   
Host: armv7hl-redhat-linux-gnueabi Target:
Build: Last reconfirmed:

Description Florian Weimer 2018-10-27 10:39:19 UTC 
On Fedora armhfp (armv7hl-redhat-linux-gnueabi), time/tst-mktime2 fails like this:

info: setting TZ=America/Sao_Paulo
tst-mktime2.c:87: numeric comparison failure
   left: -1 (0xffffffff); from: mktime (lt)
  right: 2147483647 (0x7fffffff); from: now
tst-mktime2.c:87: numeric comparison failure
   left: -1 (0xffffffff); from: mktime (lt)
  right: -2147483648 (0x80000000); from: now
tst-mktime2.c:87: numeric comparison failure
   left: -1 (0xffffffff); from: mktime (lt)
  right: 2147483646 (0x7ffffffe); from: now
tst-mktime2.c:87: numeric comparison failure
   left: -1 (0xffffffff); from: mktime (lt)
  right: -2147483647 (0x80000001); from: now
info: setting TZ=GMT0
info: setting TZ=JST-9
info: setting TZ=EST+3EDT+2,M10.1.0/00:00:00,M2.3.0/00:00:00
info: setting TZ=PST8PDT,M4.1.0,M10.5.0
error: 4 test failures

This started after this commit:

commit 8e6fd2bdb21efe2cc1ae7571ff8fb2599db6a05a
Author: Paul Eggert <eggert@cs.ucla.edu>
Date:   Wed Sep 19 13:16:14 2018 -0700

    Merge mktime, timegm from upstream Gnulib

We do not see this failure on other architectures.
Comment 2 Florian Weimer 2018-10-27 14:46:41 UTC 
(In reply to Andreas Schwab from comment #1)
> <https://build.opensuse.org/package/live_build_log/home:Andreas_Schwab:glibc/
> glibc:testsuite/a/armv7l> doesn't have that failure.

What's your GCC version?  We saw the failure when using GCC 8.2, configured with:

        --with-tune=generic-armv7-a --with-arch=armv7-a \
        --with-float=hard --with-fpu=vfpv3-d16 --with-abi=aapcs-linux \
Comment 3 Andreas Schwab 2018-10-27 18:46:22 UTC 
gcc8-8.2.1+r264010-1.1
Comment 4 Florian Weimer 2018-11-16 14:17:43 UTC 
We don't see this failure anymore as of commit 346ef23f197a0c8ba807c344bd39101b711050ee on master.