[clang] Errors about .model files, when using --analyze on Windows

[icebox246]

Overview

When compiling with --analyze flag on Windows, .model files are created for each defined function in code. These files are named <function>.model, so when a function has a particular name (e.g. aux), it can lead to creation of a file with illegal name (e.g. aux.model) - this in turn may cause errors as such files cannot be created normally. Example problematic names are: aux, prn.

Suggested minimal test case

// problem.cpp
void aux() {}

Compilation:

$ clang problem.cpp --analyze
error: error reading 'aux.model': no such file or directory
1 error generated.

Clang version:

$ clang --version
clang version 20.1.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

[llvmbot]

@llvm/issue-subscribers-clang-static-analyzer

Author: None (icebox246)

# Overview When compiling with `--analyze` flag on Windows, `.model` files are created for each defined function in code. These files are named `<function>.model`, so when a function has a particular name (e.g. `aux`), it can lead to creation of a file with illegal name (e.g. `aux.model`) - this in turn may cause errors as such files cannot be created normally. Example problematic names are: `aux`, `prn`.

Suggested minimal test case

// problem.cpp
void aux() {}

Compilation:

$ clang problem.cpp --analyze
error: error reading 'aux.model': no such file or directory
1 error generated.

Clang version:

$ clang --version
clang version 20.1.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin

[steakhal]

Hello, I don't have access to Windows machines. Because of this, I'd need assistance to sort this out.
Are you sure you are using an unmodified clang?
Model files are for bodyfarmed functions, which is enabled by overriding the default empty "model-path" config to a non-empty valid path to a directory holding a bunch of fn.model files - like the one you see the complaint about.
This makes me wonder, how did you hit that code path in a harmless command-line you shared.

You could pass the -### flag to see the actual clang driver flags that the analyzer would see.
What is the output of clang problem.cpp --analyze -### ?

[icebox246]

Hello, yes I am using unmodified version of clang installed via winget (LLVM.LLVM package in winget source - which seems be downloaded from github releases)

$ clang problem.cpp --analyze -###
clang version 20.1.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
 (in-process)
 "C:\\Program Files\\LLVM\\bin\\clang.exe" "-cc1" "-triple" "x86_64-pc-windows-msvc19.24.28316" "-analyze" "-disable-free" "-clear-ast-before-backend" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "problem.cpp" "-analyzer-checker=core" "-analyzer-checker=apiModeling" "-analyzer-checker=unix.API" "-analyzer-checker=unix.Malloc" "-analyzer-checker=unix.MallocSizeof" "-analyzer-checker=unix.MismatchedDeallocator" "-analyzer-checker=unix.cstring.BadSizeArg" "-analyzer-checker=unix.cstring.NullArg" "-analyzer-checker=deadcode" "-analyzer-checker=cplusplus" "-analyzer-checker=security.insecureAPI.UncheckedReturn" "-analyzer-checker=security.insecureAPI.getpw" "-analyzer-checker=security.insecureAPI.gets" "-analyzer-checker=security.insecureAPI.mktemp" "-analyzer-checker=security.insecureAPI.mkstemp" "-analyzer-checker=security.insecureAPI.vfork" "-analyzer-checker=nullability.NullPassedToNonnull" "-analyzer-checker=nullability.NullReturnedFromNonnull" "-analyzer-output" "plist" "-w" "-setup-static-analyzer" "-mrelocation-model" "pic" "-pic-level" "2" "-mframe-pointer=none" "-relaxed-aliasing" "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" "-mconstructor-aliases" "-fms-volatile" "-funwind-tables=2" "-target-cpu" "x86-64" "-tune-cpu" "generic" "-fdebug-compilation-dir=PATH_TO_CURRENT_FOLDER" "-fcoverage-compilation-dir=PATH_TO_CURRENT_FOLDER" "-resource-dir" "C:\\Program Files\\LLVM\\lib\\clang\\20" "-internal-isystem" "C:\\Program Files\\LLVM\\lib\\clang\\20\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.24.28314\\include" "-internal-isystem" "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\Community\\VC\\Tools\\MSVC\\14.24.28314\\atlmfc\\include" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.18362.0\\ucrt" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.18362.0\\shared" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.18362.0\\um" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.18362.0\\winrt" "-internal-isystem" "C:\\Program Files (x86)\\Windows Kits\\10\\Include\\10.0.18362.0\\cppwinrt" "-fdeprecated-macro" "-ferror-limit" "19" "-fmessage-length=161" "-fno-use-cxa-atexit" "-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.24.28316" "-std=c++14" "-fskip-odr-check-in-gmf" "-fdelayed-template-parsing" "-fcxx-exceptions" "-fexceptions" "-fcolor-diagnostics" "-faddrsig" "-o" "problem.plist" "-x" "c++" "problem.cpp"

[steakhal]

Thank you. Can anyone else reproduce this?

BTW, I notice you use clang and not clang++ for c++ files. Is it intentional?
Would it work if you would use clang++ --analyze problem.cpp?

[icebox246]

BTW, I notice you use clang and not clang++ for c++ files. Is it intentional? Would it work if you would use clang++ --analyze problem.cpp?

Yes the same result appears when using clang++ and also when compiling C files with clang.

[steakhal]

Hopefully, eventually someone on Windows decide to look into this. I'm still puzzled how could this be the case, but I guess we will fine out eventually. I don't plan to investigate this issue myself. Sorry.