pgousseau added a comment. > > On Linux, if the timestamp of a header file, included in the pch, is > > modified, then including the pch without regenerating it causes a fatal > > error, which is reasonable.
> > > On Windows the check is ifdefed out, allowing the compilation to continue > > in a broken state. > > > The root of the broken state is that, if timestamps dont match, the > > preprocessor will reparse a header without discarding the pch data. > > > This leads to "#pragma once" header to be included twice. > > > The reason behind the ifdefing of the check lacks documentation, and was > > done 6 years ago. > > It's documented in the comment you deleted: > > // In our regression testing, the Windows file system seems to > // have inconsistent modification times that sometimes > // erroneously trigger this error-handling path. > > > We should confirm whether this is in fact still the case. Maybe this is > caused by building on a networked file system, where a locally-changed file > might have a different mtime locally and remotely (the local mtime may be > precise where the remote one has been rounded to a multiple of 2 seconds by > an underlying FAT filesystem)? If it's something like that, we could perhaps > work around this by rounding the mtime to a multiple of 2 seconds ourselves. I am not sure how to reproduce this build scenario, would you be able to provide some more stepped details? I have tried emitting and including a PCH on a networked FAT32 drive, but no false warnings observed so far. Are you asking for the 2 seconds tolerance to be part of this patch? Or, as it seems the main problem here is the lack of a reproducible, are you ok with the idea of committing this patch first, to see if the inconsistent time stamps is still an issue? http://reviews.llvm.org/D20867 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
