This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: ak at suse dot de, gcc at gcc dot gnu dot org, linux-kernel at vger dot kernel dot org
- Date: Thu, 1 Apr 2004 15:51:33 -0500 (EST)
- Subject: Re: Linux 2.6 nanosecond time stamp weirdness breaks GCC build
Andi Kleen writes:
> The solution from back then I actually liked best was to just round
> up to the next second instead of rounding down when going from 1s
> resolution to ns.
(My understanding of kernel internals is way rusty, so if I am
talking nonsense here, just hit me with a cluestick or ignore
me or something).
Ummm, I think that will just fail in the converse way if
insn-conditions.o is retained in the inode cache while
insn-conditions.c is dropped from the cache?
That is, consider these time-stamps:
insn-conditions.c SSSS.NS1
insn-conditions.o SSSS.NS2
Where SSSS is the same value on both files, and NS2 > NS1.
According to Ulrich, the current problem is that insn-conditions.o
is dropped from the cache, so NS2 becomes 0, and insn-conditions.o
becomes older than insn-conditions.c.
With your patch, suppose that insn-conditions.c is dropped from the
cache, while insn-conditions.o remains. Then the timestamps will be:
insn-conditions.c SSSS+1.0
insn-conditions.o SSSS.NS2
We lose again, insn-conditions.c has become newer than insn-conditions.o.
insn-conditions.c is a generated file so I think this can actually
happen during a gcc build.
Michael C