[PATCH] [llvm-ranlib] Take in consideration UTC offset for D-flag.test

[zatrazz]

Summary

The llvm-ar uses localtime to print the object timestamp and it is
subject to UTC offset (daylight for instance). The patch changes
the test to check against output of a 'date' command.

It fixes the D-flag.test failure on some aarch64 and arm bots,
which are situated on GMT with currently BST timezone.

[kristof.beyls]

llvm/test/tools/llvm-ranlib/D-flag.test

13

I wonder if 'date' is available on all platforms that LLVM builds on. For example, is it available on Windows (with GnuWin32 installed, as per the requirements listed at https://llvm.org/docs/GettingStartedVS.html)? http://gnuwin32.sourceforge.net/packages.html doesn't seem to list "date" explicitly?

[arichardson]

I was careful in the test to use TZ=UTC for all commands printing dates and it works fine for me in UTC+1 and in the UK which is currently UTC. Does the bot in question ignore the TZ variable?

[arichardson]

llvm/test/tools/llvm-ranlib/D-flag.test

23

Wouldn't this line also have to change?

[zatrazz]

Updated patch based on previous comments.

[zatrazz]

llvm/test/tools/llvm-ranlib/D-flag.test

13

It is provided by coreutils (http://gnuwin32.sourceforge.net/packages/coreutils.htm).

23

It does and I updated the patch.

[arichardson]

I'm fine with this workaround although I'm very surprised that the test is not working. Especially since deterministic-archive.test and replace-update.test also set TZ to get reproducible output

Do you have access to any of the failing bots? If so what happens there if you change the TZ variable?
I get the following on all systems I have access to when I run something like date && date -u && env TZ=CET date && env TZ=CET date -u && env TZ=BST date && env TZ=BST date -u I get the following output:

Thu  9 Jan 2020 20:18:10 GMT
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 21:18:10 CET
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC

[zatrazz]

In D72449#1812130, @arichardson wrote:

I was careful in the test to use TZ=UTC for all commands printing dates and it works fine for me in UTC+1 and in the UK which is currently UTC. Does the bot in question ignore the TZ variable?

The issue is setting TZ=UTC still might use internal database with UTC offsets. For instance, on the buildbot
that accused the regression, setting TZ=UTC make it use the tz database /usr/share/zoneinfo/UTC. At least
on Linux with glibc one way to actually use UTC without transit changes are to set TZ=":", it won't try to
access either the default '/etc/localtime'. However, I am not sure how portable it is and it might be in fact
an glibc issue (https://sourceware.org/bugzilla/show_bug.cgi?id=24004).

[zatrazz]

In D72449#1812818, @arichardson wrote:

I'm fine with this workaround although I'm very surprised that the test is not working. Especially since deterministic-archive.test and replace-update.test also set TZ to get reproducible output

Do you have access to any of the failing bots? If so what happens there if you change the TZ variable?
I get the following on all systems I have access to when I run something like date && date -u && env TZ=CET date && env TZ=CET date -u && env TZ=BST date && env TZ=BST date -u I get the following output:

Thu  9 Jan 2020 20:18:10 GMT
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 21:18:10 CET
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC
Thu  9 Jan 2020 20:18:10 UTC

I am not sure now if it was something wrong with the bot tzdata, I reinstalled the tzdata packages
and reconfigured the timezone and now 'TZ=UTC date -d '@0' +%H:%M' does show the expected
00:00.

Indeed, although the workaround shouldn't change the expected result, the issue I am observing
on some machine does not make sense (TZ=UTC date -d '@0' +%H:%M' not showing 00:00).

I will hold this and investigate further.

llvm/test/tools/llvm-ranlib/D-flag.test

 ## Test the -D and -U flags of llvm-ranlib
 ## Create an archive with timestamps but without symbol table
 ## Important: all `llvm-ar tv` calls must use TZ=UTC to produce identical values
 # RUN: yaml2obj %S/../llvm-ar/Inputs/add-lib1.yaml -o %t.o
 # RUN: env TZ=UTC touch -t 200001020304 %t.o
 # RUN: rm -f %t.a %t-no-index.a && llvm-ar cqSU %t-no-index.a %t.o
 
 ## Check that the intial listing has real values:
 # RUN: env TZ=UTC llvm-ar tv %t-no-index.a | FileCheck %s --check-prefix=REAL-VALUES
 
 ## Check that the -D flag clears the timestamps:
 # RUN: cp %t-no-index.a %t.a && llvm-ranlib -D %t.a
-# RUN: env TZ=UTC llvm-ar tv %t.a | FileCheck %s --check-prefix=DETERMINISTIC-VALUES
+# RUN: (env TZ=UTC date -d '@0' +%H:%M; env TZ=UTC llvm-ar tv %t.a) | FileCheck %s --check-prefix=DETERMINISTIC-VALUES
 
 ## Check that the -U flag maintains the timestamps:
 # RUN: cp %t-no-index.a %t.a && llvm-ranlib -U %t.a
 # RUN: env TZ=UTC llvm-ar tv %t.a | FileCheck %s --check-prefix=REAL-VALUES
 
 ## Check that we accept multiple values and the last one wins:
 # RUN: cp %t-no-index.a %t.a && llvm-ranlib -UDU %t.a
 # RUN: env TZ=UTC llvm-ar tv %t.a | FileCheck %s --check-prefix=REAL-VALUES
 # RUN: cp %t-no-index.a %t.a && llvm-ranlib -UUD %t.a
 # RUN: env TZ=UTC llvm-ar tv %t.a | FileCheck %s --check-prefix=DETERMINISTIC-VALUES
 
 ## Check arguments can be passed before and after the file name
 # RUN: cp %t-no-index.a %t.a && llvm-ranlib -U %t.a -D -U
 # RUN: env TZ=UTC llvm-ar tv %t.a | FileCheck %s --check-prefix=REAL-VALUES
 
 ## Check that the -D/-U option is only accepted with a single dash. This matches
 ## the GNU ranlib behaviour.
 # RUN: not llvm-ranlib --D %t.a 2>&1 | FileCheck %s --check-prefix=BAD-OPT-D
 # BAD-OPT-D: error: Invalid option: '--D'
 # RUN: not llvm-ranlib --U %t.a 2>&1 | FileCheck %s --check-prefix=BAD-OPT-U
 # BAD-OPT-U: error: Invalid option: '--U'
 # RUN: not llvm-ranlib -x %t.a 2>&1 | FileCheck %s --check-prefix=BAD-OPT-x
 # BAD-OPT-x: error: Invalid option: '-x'
 
 ## If the first argument starts with value flags, the error message only shows
 ## the remainder of the parsed string:
 # RUN: not llvm-ranlib -Dx %t.a 2>&1 | FileCheck %s --check-prefix=BAD-OPT-x
 # RUN: not llvm-ranlib -DxD %t.a 2>&1 | FileCheck %s --check-prefix=BAD-OPT-xD
 # BAD-OPT-xD: error: Invalid option: '-xD'
 
-# DETERMINISTIC-VALUES: {{[rwx-]+}} 0/0    712 Jan  1 00:00 1970 D-flag.test.tmp.o
+## llvm-ar uses localtime to print the object timestamp and it is subject to
+## UTC offset (daylight for instance).
+# DETERMINISTIC-VALUES: [[HHMM:[0-9]+:[0-9]+]]
+# DETERMINISTIC-VALUES: {{[rwx-]+}} 0/0    712 Jan  1 [[HHMM]] 1970 D-flag.test.tmp.o
 # REAL-VALUES: {{[rwx-]+}} {{[0-9]+}}/{{[0-9]+}} 712 Jan  2 03:04 2000 D-flag.test.tmp.o