[lld] [LLD] Use uint64_t timestamp to overcome potential overflow (PR #81665)

Martin Storsjö via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 13 13:35:12 PST 2024


https://github.com/mstorsjo requested changes to this pull request.

I do not understand the rationale of this change.

The COFF header has a 32 bit timestamp field. It does not make anything better to pretend that the field is 64 bit on the driver frontend - we still can't store anything outside of the 32 bit range.

I do not know what "potential overflow within some expressions are" you refer to, you need to elaborate on exactly what overflows you refer to.

The issues noted in 0bf4ff29816c0eead99ba576a2df2e3c4d214b1f are related to specifically to printing the timestamps with llvm-readobj, not to any issues within LLD itself.

While you don't say exactly what issues you are addressing, one wild guess is that you are doing builds with `SOURCE_DATE_EPOCH` set to random values throughout the whole 64 bit timestamp range, and since 0df8aed6c30f08ded526038a6bbb4daf113a31c1, your builds are erroring out. Is this the case?

https://github.com/llvm/llvm-project/pull/81665


More information about the llvm-commits mailing list