This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] On-demand parsing capability for CTU
ClosedPublic

Authored by gamesh411 on Mar 5 2020, 1:31 AM.

Details

Summary

Add an option to enable on-demand parsing of needed ASTs during CTU analysis.
Two options are introduced. CTUOnDemandParsing enables the feature, and
CTUOnDemandParsingDatabase specifies the path to a compilation database, which
has all the necessary information to generate the ASTs.

Diff Detail

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
martong added inline comments.Mar 5 2020, 10:28 AM
clang/lib/CrossTU/CrossTranslationUnit.cpp
407

CI.getPCHContainerOperations() is probably not needed, because we are not going to exercise the ASTReader, so this could be a nullptr (default param value).

martong added inline comments.Mar 5 2020, 10:31 AM
clang/lib/StaticAnalyzer/Core/CallEvent.cpp
578 ↗(On Diff #248408)

left here some debugging

balazske added inline comments.Mar 5 2020, 11:55 PM
clang/include/clang/CrossTU/CrossTranslationUnit.h
231

class would look better here? (The descendants are class too.)

234

Probably it is good to mention in the documentation that the function is used with a string read from a file and the type of the file determines the meaning of the Identifier here (the calling code does have no direct knowledge about it).

clang/lib/CrossTU/CrossTranslationUnit.cpp
454

matches

493

Members of ASTOnDemandLoader would be better in a single group in the source file.

martong added inline comments.Mar 6 2020, 8:57 AM
clang/lib/CrossTU/CrossTranslationUnit.cpp
364

Could we check somehow if CTUDir is indeed an absolute path? If not then probably we should bail out with an error. Though I am not sure if there is an easy and portable way in llvm:: to check for beeing an absolute path.

369

There is no variable named as OnDemandParsingCommands, perhaps you made a rename but forgot to rename in the comments?

378

There is no variable named as ASTSourcePath, perhaps you made a rename but forgot to rename in the comments?

407

If CI.getPCHContainerOperations() is not needed then we can remove the CI member of ASTOnDemandLoader.

437

Perhaps we should make sure that Identifier is indeed an absolute path and if not then we should emit an error. If a user do not use CodeChecker to generate the ExternalDefMapping it may contain relative paths. See e.g.: https://clang.llvm.org/docs/analyzer/user-docs/CrossTranslationUnit.html#manual-ctu-analysis

451

Could we have a lit test for this case? I.e having a compile_commands.json with two ambiguous entries for the same file and then we should expect the compiler diag?
(Note, I am asking this because it is not immediate for me from the code that this will ever fire.)

clang/test/Analysis/ctu-main.c
53

Is this hunk related?

clang/test/Analysis/ctu-on-demand-parsing.c
3

Why do we need sed here? I don't see any \ in the compile commands json. Is it because of Windows builds? Could you please explain in a comment maybe in the previous line.

gamesh411 updated this revision to Diff 256212.Apr 9 2020, 1:19 AM

Refactored the test
Copying the compile_commands.json in case of test for C files
results in the extdef mapping tool finding the correct compiler
flags for the C to be imported.

The warning below suggests that we parse the ctu-other.c file (and presumably every file) as a C++ file, even if it should be parsed as a C file. Perhaps the invocation of the parser is missing some setting? Also, could this be the reason why on-the-fly and pch driven ctu gives different statistics?

warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
/mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/clang/test/Analysis/Inputs/ctu-other.c:47:26: error: 'DataType' cannot be defined in a parameter type
int structInProto(struct DataType {int a;int b; } * d) {
                         ^
1 error generated.
Error while processing /mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/clang/test/Analysis/Inputs/ctu-other.c.

I have investigated the issue, and the compiler flags were looked up using the heuristic implemented in tooling.
This heuristic looks for the suitable compilation database in an upward ascending fashion inside the directory tree startin from the input source file.
By copying both the source file and the compilation database to the test directory this heuristic does the right thing now. (up until now the found compile_commands.json was the one used for llvm-project itself, and picked up a c++ specific compilation).

This issue is solved, however the ASTImporter still cannot import the inline definition of the struct, and emits an error.
Right now I am debugging the master branch that uses the AST-dumps wheter I also encounter this error inside the ASTImporter (just to see if I am operating on sane assumptions).

As the CTUDir string prefix is only needed in case of the old approach, I have refactored the external definition mapping storage to NOT include that.

Both ctu-main.c and ctu-on-demand-parsing.c use the -analyzer-config ctu-dir=%t/ctudir2 setting. So it is not clear for me why we don't need the prefix. I believe we still need that directory setting otherwise where could we find the externalDefMap file?

You are right, the ctudir2 prefix is not needed as the %t substitution is test-file-level unique.

The warning below suggests that we parse the ctu-other.c file (and presumably every file) as a C++ file, even if it should be parsed as a C file. Perhaps the invocation of the parser is missing some setting? Also, could this be the reason why on-the-fly and pch driven ctu gives different statistics?

warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
/mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/clang/test/Analysis/Inputs/ctu-other.c:47:26: error: 'DataType' cannot be defined in a parameter type
int structInProto(struct DataType {int a;int b; } * d) {
                         ^
1 error generated.
Error while processing /mnt/disks/ssd0/agent/workspace/amd64_debian_testing_clang8/clang/test/Analysis/Inputs/ctu-other.c.

I have investigated the issue, and the compiler flags were looked up using the heuristic implemented in tooling.
This heuristic looks for the suitable compilation database in an upward ascending fashion inside the directory tree startin from the input source file.
By copying both the source file and the compilation database to the test directory this heuristic does the right thing now. (up until now the found compile_commands.json was the one used for llvm-project itself, and picked up a c++ specific compilation).

This issue is solved, however the ASTImporter still cannot import the inline definition of the struct, and emits an error.
Right now I am debugging the master branch that uses the AST-dumps wheter I also encounter this error inside the ASTImporter (just to see if I am operating on sane assumptions).

I've been looking into this and the ASTImporter indeed does not (cannot) import the definition of structInProto(). But that's just fine, that is why we have a branching for the call expression (TRUE/FALSE) below in ctu-main.c . All other functions whose definition were imported gives only the TRUE branch.

clang_analyzer_eval(structInProto(&d) == 0); // expected-warning{{TRUE}} expected-warning{{FALSE}}
gamesh411 updated this revision to Diff 257622.Apr 15 2020, 1:35 AM

Reorganize test code to overcome testing infrastructure limitations

The tests are getting better, thanks Endre!

clang/test/Analysis/ctu-on-demand-parsing.c
6

Why do we need the -Wno-visibility flag?

7

If we execute clang_extdef_map then we don't need Inputs/ctu-other.c[pp].externalDefMap.on-the-fly.txt files. Do we?

gamesh411 marked 23 inline comments as done.Apr 15 2020, 1:53 PM

Answered most review comments. Thanks for the reviewers @balazske, @martong so far.
The question of absolute path policy is still up for debate.

clang/lib/CrossTU/CrossTranslationUnit.cpp
364

Actually this does not need to be absolute. The naming of the variable should be changed to PrefixedPath or similar. I will do that for now.

364

It not necessarily an absolute path, only prefixed by CTUDir. There is no clear policy as to where to use strictly absolute paths and where to accept relative paths. IMHO this should be considered, and I am most certainly open for a discussion. In the meantime, I will just rename the variable to PrefixedPath.

407

As for the automatic lifetime of Tool, I am inclined to say this is not the case. I have run my clang-build with sanitizers (undefined and memory), and no bad access or UB was reported. If someone has more domain knowledge about tooling and the lifetime issues that could arise, I would be thrilled to be enlightened.

407

As for the need to pass PCHContainerOperaitons:
I think you are right, and I will check if this modifies the behaviour of the import in any way. I am removing this for now.

437

The policy of absolute and relative paths should be discussed. See my previous answer concerning AbsPath variable above. BTW llvm::sys::path::is_absolute is a solution for asserting this as I see it.

clang/test/Analysis/ctu-main.c
53

Seems unrelated, not sure how it got included. Fixing it.

clang/test/Analysis/ctu-on-demand-parsing.c
3

I have done this by example. Some CodeGen lit tests use sed the same way I did here. Needed for Windows compatibility maybe? (note that %t could substitute into a path containing backslashes on Windows) However, on Windows platforms, the availability of sed is not guaranteed either. The backslashes are used as escape chars in the JSON, hence the need to double-escape them. No comments are provided on those test also... I will add something tho (and also in the cpp test).

gamesh411 marked 7 inline comments as done.Apr 15 2020, 4:49 PM
gamesh411 added inline comments.
clang/test/Analysis/ctu-on-demand-parsing.c
6

Needed because the in-expression definition of a struct (which we cannot import) also warrants a compiler warning, and this comes up 2 times even (once when generating the extdef-mapping, second time when we analyze the file). Its easier to handle this warning in the compilation database, as that removes both occurrences of the warning.

7

Cannot remove as of yet, because they have .ast suffixed entries. In order to remove them the whole logic of what should be inside the index (externalDefMap.txt) for on-demand and non-on-demand cases should be discussed.

gamesh411 updated this revision to Diff 257896.Apr 15 2020, 4:50 PM
gamesh411 marked an inline comment as done.

Implement review suggestions

gamesh411 marked 5 inline comments as done.Apr 15 2020, 4:58 PM
gamesh411 added inline comments.
clang/lib/CrossTU/CrossTranslationUnit.cpp
451

Good idea, I will create a standalone test case for this!

gamesh411 updated this revision to Diff 257985.Apr 16 2020, 1:27 AM
gamesh411 marked an inline comment as done.

Rebase and update the number of analyzer options

Add ambiguous compilation database test case

gamesh411 updated this revision to Diff 258674.Apr 20 2020, 1:33 AM

Update user documentation

martong accepted this revision.Apr 20 2020, 4:41 AM

Thanks Endre for the docs! I checked the CI job also, seemed okay, so, I think we are ready! Nice work! Let's do the commit!

clang/docs/analyzer/user-docs/CrossTranslationUnit.rst
26

Maybe just simply write This tool uses a compilation command database ...
(Same below with the on-demand version.)

This revision is now accepted and ready to land.Apr 20 2020, 4:41 AM
xazax.hun added inline comments.Apr 20 2020, 5:08 AM
clang/include/clang/CrossTU/CrossTranslationUnit.h
52

The two enum values refer to compilation database and compile command database. I'd prefer to use the same wording in both values.

237

I am not sure if this is good design.
Here, if the meaning of the Identifier depends on the subclass, the caller of this method always needs to be aware of the dynamic type of the object. What is the point of a common base class if we always need to know the dynamic type?

Looking at the code this does not look bad. But it might be a code smell.

291

Why is this no longer const?

clang/lib/CrossTU/CrossTranslationUnit.cpp
118

Unfortunately, this is a very common case for a large number of projects that supports multiple targets (e.g. 32 and 64 bits). Is there a plan to mitigate this problem?

martong added inline comments.Apr 21 2020, 3:02 AM
clang/include/clang/CrossTU/CrossTranslationUnit.h
52

+1

237

The way how we process the extDefMapping file is identical in both cases. That's an index, keyed with the USRs of functions and then we get back a value. And the way how we use that value is different. In the PCH case that holds the path for the .ast file, in the ODM case that is the name of the source file which we must find in the compile db. So, I think the process of getting the AST for a USR requires the polymorphic behavior from the loaders.

We discussed other alternatives with Endre. We were thinking that maybe the extDefMapping file should be identical in both cases. But then we would need to add the .ast postfixes for the entries in the PCH case. And we cannot just do that, because we may not know if what is the correct postfix. The user may have generated .pch files instead. Also, we don't want to compel any Clang user to use CodeChecker (CC will always create .ast files). CTU should be running fine by manually executing the independent steps.

clang/lib/CrossTU/CrossTranslationUnit.cpp
118

I don't think we could do that. We need to merge ASTs of those TUs that are linkable. Otherwise the merge will be unsuccessful because of certain mismatches in Decls (structural eq will fail).
Even in CodeChecker we are planning to issue a hard error in these ambiguous cases, even with the PCH method too. (The error would be suppressible by the user of course, but if that is suppressed then we take no responsibility.)

xazax.hun accepted this revision.Apr 21 2020, 3:34 AM

Ok, looks good to me.

The minor nit regarding the naming is easy to fix before commit. The design question I had is not a blocker, my suggested alternative can be implemented later (if desired) in a backward-compatible way from the user's point of view.

clang/include/clang/CrossTU/CrossTranslationUnit.h
237

Let me rephrase my concerns a bit. Do we really need a polymorphic ASTLoader to be present for the whole analysis? Wouldn't it make more sense to always do the same thing, i.e. if we are given a pch file load it, if we are given a source file, parse it? This way we would not be restricted to on-demand or two pass ctu analysis, but we could do any combination of the two.

whisperity added inline comments.Apr 21 2020, 7:53 AM
clang/docs/analyzer/user-docs/CrossTranslationUnit.rst
21

I think it's PCH-based with a -.

25

symbols' USR names

26

clang tool

26

And perhaps add some cross-references to what a compilation database is, etc. These things are also documented within Clang's doc tree.

31

Instead of a prefix, create an overview of PCH-based analysis, and add this and the next one as a 3rd-level heading?

112–115

Are these flags documented somewhere?

208–209

Same here for comments from above.

312–316

These lines could be removed, I think, they don't add anything to the presentation.

317–318

Due to the lack of colours, perhaps you could use ls -F which suffixes each directory with a /: reports/.

368

as a runner script the driver for this feature

369

expect it to work only ...

(to emphasise the limitation)

clang/lib/CrossTU/CrossTranslationUnit.cpp
118

More clever logging of link commands and creating separate CDBs for each target or each binary could help this cause, but that needs infrastructural capabilities from both the build system and the analysis driver (i.e. CodeChecker).

martong added inline comments.Apr 22 2020, 7:53 AM
clang/include/clang/CrossTU/CrossTranslationUnit.h
237

Well yeah, we could do that, it is a good idea, thanks! We will consider this in the future. I like in this idea that the command line options to Clang would be simplified. But then we must be transparent and show/log the user which method we are using.

whisperity added inline comments.Apr 23 2020, 2:57 AM
clang/docs/analyzer/user-docs/CrossTranslationUnit.rst
376

What's this line? Is this added by Phab, or is this a weird merge conflict / parsing error of the patch?

gamesh411 updated this revision to Diff 260078.Apr 25 2020, 3:12 AM
gamesh411 marked 15 inline comments as done.

Fix issues in documentation

@whisperity Thanks for the review :3

clang/docs/analyzer/user-docs/CrossTranslationUnit.rst
112–115

As with ctu-dir, these flags are only documented in analyzer options. However, it would indeed be beneficial to list CTU related flags here in the user documentation. I will create a new revision for that specifically.

312–316

Good point, i remove it from here and from the above example as well.

Reword enum value

gamesh411 updated this revision to Diff 260238.Apr 27 2020, 1:25 AM

Fix index error enum declaration

gamesh411 closed this revision.Apr 27 2020, 1:57 AM

I am landing this. Thanks for the reviews @martong @balazske @xazax.hun @whisperity !

thakis added a subscriber: thakis.Apr 27 2020, 3:38 AM
thakis added inline comments.
clang/lib/CrossTU/CMakeLists.txt
13 ↗(On Diff #260238)

We've been very careful to make clang (the compiler binary) only depend on clangToolingCore and not on the much bigger clangTooling library. Since clang depends on the CrossTU library, this breaks that. Can you reorganize things so that we don't need a dependency from clang-the-compiler-binary on clangTooling?

Looks like this also breaks tests on Windows and Mac, eg http://45.33.8.238/win/13902/step_7.txt

It probably makes sense to revert while you investigate?

Sorry, this change broke a couple bots that are in the official CI, at least http://lab.llvm.org:8011/builders/llvm-clang-win-x-aarch64/builds/7566 and http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/66618. I'm reverting this change -- feel free to reland after fixing the issue.

gamesh411 reopened this revision.EditedApr 27 2020, 6:34 AM

Non-linux buildbots were utterly broken :( . Trying to fix them...

Thanks for reverting this for me :)
Also I will investigate the possibility to not depend on Tooling.

This revision is now accepted and ready to land.Apr 27 2020, 6:34 AM
gamesh411 updated this revision to Diff 260308.Apr 27 2020, 6:39 AM

Remove platform constraint from test file

gamesh411 updated this revision to Diff 260310.Apr 27 2020, 6:44 AM

[NFC] Fix arcanist double commit revisioning

gamesh411 marked an inline comment as done.Apr 27 2020, 7:18 AM
gamesh411 added inline comments.
clang/lib/CrossTU/CMakeLists.txt
13 ↗(On Diff #260238)

I have gone, and investigated where the main functionality of on-demand AST loading comes from. (Only after wishfully thinking changing the dependency from clangTooling to clangToolingCore would work, which of course didnt't )

It seems that this functionality used the major components of clangTooling, namely JSONCompilationDatabase::loadFromFile, ClangTool ctor/dtor, ClangTool::buildAST.
In order to circumvent the dependency and the reimplementation of handling compilation databases, a call to an external tool could be used, or the clangTooling library would need to be refactored in a way which is not a very tasteful refactoring. IMHO. I would like to know which of the aforementioned way is deemed to be best.

Remove arch target from another invocation

gamesh411 updated this revision to Diff 263294.May 11 2020, 3:34 PM

Implement a solution without a dependency on clangTooling

balazske added inline comments.May 12 2020, 2:16 AM
clang/lib/CrossTU/CrossTranslationUnit.cpp
363–364

Is here a lambda necessary? I think it must not be over-used. In this case we can construct the file path as the first step and then use it to load the file, without using lambda call.

555

Is here a special reason to use auto && type (and not auto & or std::string &)? Probably this code is faulty: The CmdPart is moved out and then destructed, before the content of it (where the c_str points to) is used?

Please check the summary of the patch, it seems to contain old information as well.

clang/docs/analyzer/user-docs/CrossTranslationUnit.rst
211–213

This is obsolete information.

clang/include/clang/CrossTU/CrossTranslationUnit.h
244

Is the explicit needed here?

clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.def
394–395

"valid compilation database" is this line still what we wish to say? A YAML is used, so most likely we need a "valid invocation list" or something.

399–404

Maybe it would be worthwhile to add a dummy example like main.cpp: g++ hello-world.cpp which has the proper format into this help.

clang/lib/CrossTU/CrossTranslationUnit.cpp
21–24

The idea here was to not depend on libtooling but these lines are still here!

32

<> -> "" and order

117–118

still using terms "compilation database", is this intended?

555

@balazske This is a generic lambda where auto&& is the universal reference. It is equivalent to writing template <typename T> f(T&& param). It obeys the usual point of instantiation and reference cascading rules, if a const std::string& is given as T, const std::string& && will become a single &.

581

Are the headers from which these types come from included?

clang/test/Analysis/Inputs/ctu-other.c
34–38

Possibly unrelated change?

clang/test/Analysis/ctu-on-demand-parsing.c
2–16

Does the LIT syntax allow for better organising these commands? This is now a bit hard to read

Something like this would help:

// RUN: rm -rf %t && mkdir -p %t
// RUN: cp "%s" "%t/ctu-on-demand-parsing.c" && cp "%S/Inputs/ctu-other.c" "%t/ctu-other.c"
// [empty]
// [comment]
// RUN: [json magic]
// RUN: [yaml magic]
// [empty]
// RUN: extdef map
// [empty]
// RUN: cc1
whisperity requested changes to this revision.May 12 2020, 4:38 AM

(Maybe this will make Phab not show "✅ Accepted"...)

This revision now requires changes to proceed.May 12 2020, 4:38 AM

Hi Endre, just checked the latest update. Overall looks good to me, but found some nits.

clang/include/clang/CrossTU/CrossTranslationUnit.h
252

Should we rename this member to ....PathTo....InvocationList... ?

clang/lib/CrossTU/CrossTranslationUnit.cpp
553

Could we avoid this transfer if InvocationList was storing const char * values instead of std::strings? Why can't we store char*s in InvocationList?

565

typo: filed -> field

clang/test/Analysis/ctu-on-demand-parsing.c
7

Perhaps we could document here that the compile_commands.json is needed ONLY for %clang_extdef_map.

clang/test/Analysis/ctu-on-demand-parsing.cpp
10

I know this is just a nit, but this is very hard to read. Do you think we could break this up (and other long lines) into multiple lines but within the same RUN directive?

gamesh411 updated this revision to Diff 266473.May 27 2020, 3:37 AM
gamesh411 marked 29 inline comments as done.

Update functional changes, documentation update incoming

gamesh411 marked 2 inline comments as done.May 27 2020, 4:18 AM

The remaining documentation and test changes are also underway.

clang/include/clang/CrossTU/CrossTranslationUnit.h
237

I will implement this separation by suffixes in the next change.

244

This constructor started out with having a single param only. I agree, that explicit is no longer necessary.

252

Renamed to InvocationListFilePath.

291

Most usages of the CI require a non-const ref (this is due to lacking API support for getting analyzer options), and I found it more convenient to just take a non-const ref, instead of const_casting it away later. Not sure myself, but I think I will roll with this now (and I should definitely check the API of CompilerInstance).

clang/lib/CrossTU/CrossTranslationUnit.cpp
117–118

renamed

118

I have solved the problem of supporting multiple architectures by offloading the responsibility to the user (to the tool driving the analysis). The invocation list file is now supposed to contain only invocations with the same arch/target and this should also be the same as the arch/target of the main TU analyzed. If there is still ambiguity after this separation, this error should nevertheless be emitted ( IMHO ).

363–364

Refactored to use path concatenation.

553

We certainly could, I think there won't be null-characters in paths so storing char* s would not lose generality. However, I think the memory management done by std::string is worth it, as it is clear where the character-data lives in memory.

555

Results of my research: In theory, the STL could do something fancy here if it wanted, but it is not the case in reality. If you want move-operations with algorithms (the ones not explicitly mentioning move in their names) you have to be explicit about it: move-iterators-fluent-cpp.

581

Included the llvm/Support/YAMLParser.h

clang/test/Analysis/Inputs/ctu-other.c
34–38

Funny enough, this is very relevant. Dumping the AST does not errors out on this construction, however, the parser in on-demand mode does. This asm syntax is however supported by both. To document this, I have added a TODO as well.

gamesh411 marked an inline comment as done.May 27 2020, 5:33 AM
whisperity resigned from this revision.May 28 2020, 1:01 AM
whisperity added inline comments.
clang/lib/CrossTU/CrossTranslationUnit.cpp
24

Duped include in L34.

This revision is now accepted and ready to land.May 28 2020, 1:01 AM
gamesh411 updated this revision to Diff 267143.May 29 2020, 1:43 AM
gamesh411 marked 6 inline comments as done.

Fix documentation and commit message

gamesh411 marked 3 inline comments as done.May 29 2020, 1:51 AM
martong accepted this revision.May 29 2020, 3:10 AM

LGTM!

gamesh411 updated this revision to Diff 269439.Jun 9 2020, 1:37 AM

Extend index file format
Update documentation

gamesh411 updated this revision to Diff 269527.Jun 9 2020, 6:36 AM

Fix test case, and reorder warning

whisperity added inline comments.Jun 9 2020, 7:29 AM
clang/lib/CrossTU/CrossTranslationUnit.cpp
119–120

These two lines could be formatted together.

clang/unittests/CrossTU/CrossTranslationUnitTest.cpp
269

Just for good measure, I would like a test case on the "invocation list is ambiguous" error. (So in case we in the future figure out how to disambiguate, we can remove that test case!)

gamesh411 updated this revision to Diff 269615.Jun 9 2020, 11:26 AM

use consumeError in test

gamesh411 updated this revision to Diff 269639.Jun 9 2020, 12:56 PM

add ambiguous invocation list test case

gamesh411 marked 2 inline comments as done.Jun 9 2020, 12:58 PM
gamesh411 updated this revision to Diff 269677.Jun 9 2020, 2:22 PM

add ambiguity checking during invocation list parsing

This revision was automatically updated to reflect the committed changes.

This breaks check-clang on mac: http://45.33.8.238/mac/15258/step_7.txt

Please take a look, and revert for now if it takes a while to fix.

This breaks check-clang on mac: http://45.33.8.238/mac/15258/step_7.txt

Please take a look, and revert for now if it takes a while to fix.

Thanks for reporting this, i think the output is valuable for debugging. I have restricted the test case to linux for now.

clang/test/Analysis/Inputs/ctu-other.c