OikawaKirie added a comment. I think I have found out the reason for the problem, and it proved my guesses.
When executing the test case of the static analyzer, we usually use `%clang_analyze_cc1` as the entry, which is `%clang_cc1 -analyze`. And we usually do not set a target triple, as it is not required by the analyzer. However, things are complicated in Darwin Unix. In Darwin, the default target triple is `ARCH-apple-darwinXX.XX.XX`, where `ARCH` is the architecture (e.g. `x86_64`) and `XX.XX.XX` is the version of the Darwin system. And the default target triple will be then adjusted to `ARCH-apple-SYSTEMXX.XX.XX` by the `Driver::Darwin::ComputeEffectiveClangTriple` in driver related code, where `SYSTEM` can be `watchos`, `tvos`, `ios` and `macosx`. In the clang driver, the adjusted target triple will be passed to the new cc1 process; whereas in tooling and `ASTUnit::LoadFromCommandLine`, the adjusted target triple will be used to generate cc1 arguments to create `CompilerInvocation`. But when executing bare `clang -cc1`, if the target triple argument is not provided, it remains the default `ARCH-apple-darwinXX.XX.XX`. And this is the reason for the conflict. The CTU on-demand-parsing mechanism uses `ASTUnit::LoadFromCommandLine` to load external ASTs. The tool `clang-check` uses clang tooling to parse the entry file. Therefore, both target triples are the adjusted ones, which can be matched. And so is the driver (`clang --analyze ...`). But not the bare `%clang_cc1`, its target triple is the default one. --- Let's have a look at the simple example, suppose externalDefMap.txt and invocations.yaml are generated correctly. input.cc: void bar(); void foo() { bar(); } importee.cc: void bar() { } --- Using driver: clang -v --analyze input.cc -Xanalyzer -analyzer-config -Xanalyzer experimental-enable-naive-ctu-analysis=true,ctu-dir=. Output: OK, adjusted to adjusted (in-process) /path/to/clang-15 -cc1 -triple x86_64-apple-macosx10.15.0 ... --- Using clang-check: clang-check -analyze input.cc -- -v -Xanalyzer -analyzer-config -Xanalyzer experimental-enable-naive-ctu-analysis=true,ctu-dir=. Output: OK, adjusted to adjusted clang Invocation: "/path/to/clang-tool" "-cc1" "-triple" "x86_64-apple-macosx10.15.0" --- Using cc1: clang -cc1 -v -analyze input.cc -analyzer-checker=core -analyzer-config experimental-enable-naive-ctu-analysis=true,ctu-dir=. Output: ERROR, default to adjusted warning: imported AST from 'importee.cc' had been generated for a different target, current: x86_64-apple-darwin19.6.0, imported: x86_64-apple-macosx10.15.0 [-Wctu] --- What do you think is a better way to fix this problem? @gamesh411 @steakhal @martong Using `clang-check` to run the test case seems to be a good way to overcome the problem, but the problem still exists. However, IMO it is not a good idea to make clang cc1 to adjust the default target triple manually. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D102669/new/ https://reviews.llvm.org/D102669 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits