[PATCH] D108332: Have lit preserve SOURCE_DATE_EPOCH

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D108332#2956003 <https://reviews.llvm.org/D108332#2956003>, @tstellar wrote:

> In D108332#2955970 <https://reviews.llvm.org/D108332#2955970>, @dblaikie wrote:
>
>> In D108332#2955923 <https://reviews.llvm.org/D108332#2955923>, @serge-sans-paille wrote:
>>
>>>> Though this change would only have an effect on the test behavior, right? Is that a problem for some build systems? I know some are really pedantic about reproducibility even of the test results, but haven't seen any that pedantic outside of Google (& probably Facebook) - and at least at Google I don't think we've hit this, perhaps because we don't build zlib with that hardware support?
>>>
>>> That seems to be specific to SystemZ, which may not be used at Google / Facebook (?)
>>
>> Yeah, I don't think it is - but it was specifically the overlap of SystemZ and a pedantically strict build system (that requires/values bit-identical reproducibility even for test artifacts). Do you have experience with such a build system that motivated this change?
>
> It's not the build system that's being pedantic here, it is the reference output in the clang test cases:
>
> FAIL: Clang :: Modules/embed-files-compressed.cpp (8052 of 29120)
> FAIL: Clang :: Modules/stress1.cpp (8330 of 29120)

Oh, thanks!

If that's the case - maybe these tests are over-constrained? If zlib doesn't guarantee this behavior, but our tests are depending on it, the tests should probably be changed? (I can't read the regex straight up, but it looks like embed-files-compressed.cpp is at least trying to be a /bit/ fuzzy about the specific compressed size it's looking for, if it's not fuzzy enough perhaps it could be made more fuzzy? stress1.cpp doesn't immediately pop out to me - oh, it's looking for identical output from two compressed files & this comes up against the zlib hardware compression "and when the respective buffers have the same offset relative to the start of the page." condition, I take it? That does seem like a bit of a heavy burden in terms of reproducibility even on the same machine, making the same library calls...


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D108332/new/

https://reviews.llvm.org/D108332