-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[Flang][Windows] Disable PCH on Windows for flangFrontend #134726
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
This patch fixes PCH staleness errors (fatal error: ... mtime changed) for flangFrontend during incremental Windows builds. The error occurs because the automatic CMake re-run during incremental builds updates the timestamp of the PCH source file (cmake_pch.cxx) relative to the existing PCH artifact (.pch). This happens even without direct modifications to the headers listed for precompilation. Apparently, flangFrontend is the only known LLVM target which uses target_precompile_headers, and this mechanism fails to reliably force a PCH rebuild after the CMake re-run in this Windows environment.
@llvm/pr-subscribers-flang-driver Author: Omair Javaid (omjavaid) ChangesThis patch fixes PCH staleness errors (fatal error: ... mtime changed) for flangFrontend during incremental Windows builds. The error occurs because the automatic CMake re-run during incremental builds updates the timestamp of the PCH source file (cmake_pch.cxx) relative to the existing PCH artifact (.ph). This happens even without direct modifications to the headers listed for precompilation. Apparently, flangFrontend is the only known LLVM target which uses target_precompile_headers, and this mechanism fails to reliably force a PCH rebuild after the CMake re-run in this Windows environment. This was observed on https://lab.llvm.org/staging/#/builders/206/builds/1835 with following log > Full diff: https://github.com/llvm/llvm-project/pull/134726.diff 1 Files Affected:
diff --git a/flang/lib/Frontend/CMakeLists.txt b/flang/lib/Frontend/CMakeLists.txt
index e8a098613e26f..576d09f7f364c 100644
--- a/flang/lib/Frontend/CMakeLists.txt
+++ b/flang/lib/Frontend/CMakeLists.txt
@@ -73,10 +73,16 @@ add_flang_library(flangFrontend
clangDriver
)
-target_precompile_headers(flangFrontend PRIVATE
- [["flang/Parser/parsing.h"]]
- [["flang/Parser/parse-tree.h"]]
- [["flang/Parser/dump-parse-tree.h"]]
- [["flang/Lower/PFTBuilder.h"]]
- [["flang/Lower/Bridge.h"]]
-)
+# Precompiled Headers for flangFrontend
+# Only enable PCH on non-Windows platforms, as the current usage of
+# target_precompile_headers appears fragile during incremental builds
+# involving CMake regeneration specifically on Windows.
+if(NOT WIN32)
+ target_precompile_headers(flangFrontend PRIVATE
+ [["flang/Parser/parsing.h"]]
+ [["flang/Parser/parse-tree.h"]]
+ [["flang/Parser/dump-parse-tree.h"]]
+ [["flang/Lower/PFTBuilder.h"]]
+ [["flang/Lower/Bridge.h"]]
+ )
+endif()
|
Would this be fixed by #131397? |
It should be, this buildbot error was part of the reason for that PR in the first place. We should definitely merge that one then take another look at whether this is required. |
@mrkajetanp I am wondering if you can revert #130600 and only merge it alongwith #131397. This should at least help us make buildbot green again. Otherwise more failures will keep piling up. |
There were some other Windows issues, so for the time being I reverted the pch patch as requested. |
This patch fixes PCH staleness errors (fatal error: ... mtime changed) for flangFrontend during incremental Windows builds.
The error occurs because the automatic CMake re-run during incremental builds updates the timestamp of the PCH source file (cmake_pch.cxx) relative to the existing PCH artifact (.ph). This happens even without direct modifications to the headers listed for precompilation.
Apparently, flangFrontend is the only known LLVM target which uses target_precompile_headers, and this mechanism fails to reliably force a PCH rebuild after the CMake re-run in this Windows environment.
This was observed on https://lab.llvm.org/staging/#/builders/206/builds/1835 with following log