When trying the build llvm-18.1.3 with the following options,

-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libubwind" \
-DLLVM_TARGETS_TO_BUILD="X86" \
-DLLVM_DISTRIBUTION_COMPONENTS="cxx;cxxabi;cxx-headers" \
-DCMAKE_BUILD_TYPE=Release

receiving the following error:

https://preview.redd.it/299upxx9ucyc1.png?width=748&format=png&auto=webp&s=1978f99e99f63e72e5f818e79e14eaf796a474be

cxx-headers target worked well with older versions. not quite sure what happened. any help please ?

I'm translating some bytecode to LLVM, generating it manually from a source, and I've hit somewhat of a sore spot when storing values obtained from exception landingpads.

This code for example will work:

%9 = load ptr, ptr %1
%10 = call ptr @__cxa_begin_catch(ptr %9)
%11 = call i32 @CustomException_getCode(%CustomException* %10)

but as the original bytecode specifies a variable to use and I'd like to keep to the original structure as close as possible, it would generate something like:

%e = alloca %CustomException
; ...
%9 = load ptr, ptr %1
%10 = call ptr @__cxa_begin_catch(ptr %9)
store ptr %10, %CustomException* %e
%11 = call i32 @CustomException_getCode(%CustomException* %e)

However the %e variable obviously won't hold the same value as %10, and due to the structure of the original bytecode the "hack" of using bitcast to emulate assignment won't work, and the type must remain the same due to other code that touches it. Is there a way to do essentially %e = %10 with alloca variables?

Hey,

So, I have the following case:

block 1:

y = 0

​

block 2:

Z = mul y * (some_value)

​

block 3:

y = some non-zero value

​

Value of y can come both from block 3 and block 2. In the Code Motion pass multiplication instruction is moved to both of the blocks, therefore in the block 1 I have multiplication by 0, is there a way to optimize that?

I want to use Python scripting in lldb. The lldb documentation shows the user typing "script" to access lldb's Python interpreter and then importing the file with the user-written Python code, but apparently one can do something to make one's Python code importable without, say, modifying the interpreter's sys.path via an explicit command to the interpreter. How can one do this?

The code example is very simple.

#include <stdio.h>

int main() {
        printf("hello, world");
}

1. Generate the .i file by gcc

gcc -E test.cpp -o test.cpp.ii

2. generate .o files for .i files

clang++ -c test.cpp.ii -o test.cpp.o

The following error message is displayed.

In file included from test.cpp:1:
/usr/include/stdio.h:189:48: error: '__malloc__' attribute takes no arguments
  __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (fclose, 1))) ;
                                               ^
/usr/include/stdio.h:201:49: error: '__malloc__' attribute takes no arguments
   __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (fclose, 1))) ;
                                                ^
/usr/include/stdio.h:223:77: error: use of undeclared identifier '__builtin_free'; did you mean '__builtin_frexp'?
   noexcept (true) __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (__builtin_free, 1)));
                                                                            ^
/usr/include/stdio.h:223:77: note: '__builtin_frexp' declared here
/usr/include/stdio.h:223:65: error: '__malloc__' attribute takes no arguments
   noexcept (true) __attribute__ ((__malloc__)) __attribute__ ((__malloc__ (__builtin_free, 1)));

btw, When using gcc to generate .o files from .i files, everything works fine.

attribute ((malloc)) is a feature unique to GCC support? In this case, how to make clang generate .o files correctly

I'm on Linux (Debian Testing).

I'm using objcopy to embed a binary file into my executable. Additionally, I am cross-compiling for windows.

I am unable to use llvm-objcopy for creating the PE/COFF object file.

The following works:

objcopy --input-target binary --output-target pe-x86-64 --binary-architecture i386:x86-64 in.bin out.o

The following doesn't:

llvm-objcopy --input-target binary --output-target pe-x86-64 --binary-architecture i386:x86-64 in.bin out.o

And produces the error: llvm-objcopy: error: invalid output format: 'pe-x86-64'

What's my solution here? Is it to go back to objcopy? or am I missing an option to objcopy? Does clang/llvm/ld.lld support linking elf objects into PE executables?

​

Hi, I was planning to begin learning about LLVM compiler infrastructure and also compilers in general. What would be a great source to start? Should I learn how compilers work before doing anything with LLVM or is there a source on which I can learn them sort of parallely? (I know the very very basic structure of compilers ofcourse, but not a lot about the details)

Hi all, I am writing a final qualification paper at my university on the topic “Development of tools for analyzing the coverage of structural code for embedded systems”. I am currently writing a utility using Clang that would automate the placement of macros for creating log entries in the source code.

I have encountered some problems that I have not found a solution to, or have found, but they do not satisfy me:

1. How to correctly determine the name of the file from which the AST node was assembled? There were big problems with this, initially the tool made substitutions to library files. This has now been resolved as badly as possible. I compare, get the file name of the node origin position and search for it in the set of file paths that were specified when starting the tool, and also call the tool for each analyzed file separately.
2. After restarting the tool, the already placed macros are duplicated in the same set of files. Previously, I had a solution that took the pure text of the body of the analyzed AST node and searched for the macro name in it, but there are cases in which this method does not work.
3. At the moment, I have not come up with anything better than formatting the file before placing macros to be sure of the accuracy of method getBody()->getBeginLoc().getLocWithOffset(1) that it will exactly place the macro after the curly brace. Is there a more elegant way to do this?
4. The list of command line options when calling the tool cannot be filled through delimiters, i.e., for example, —extensions=“.cpp”, “.h”, for some reason only one at a time, like this —extensions=“.cpp” —extensions=“.h”. I couldn’t find the reason for this behavior.
5. When creating CommonOptionsParser, he swears about the lack of a compilation database file, I don’t need it and would like to bypass the output of this warning.

I would like to hear more criticism and advice in order to get the best result. The source code of the tool is available at the link: #include "clang/AST/AST.h"#include "clang/AST/ASTConsumer.h"#include "clang/ - Pastebin.com

not sure if this is the right place to ask.

can you add preprocessing steps to clangd (for example: running m4 or php before compiling the result)? and if so, how?

disclaimer: i know close to nothing about clangd.

Hello, I recently ditched Visual Studio and I installed the LLVM.LLVM Winget package. I also had to download the Visual Studio Build Tools for both clang and clang++ to work. Both compilers work, but when I tried to run lldb initially, I got no output. I did the "echo $?" and found the program was returning "False". I then ran lldb via the windows GUI and I got an error that said the python310.dll file was missing. After a quick download of the DLL file and putting it in the same directory of lldb I got what you see below. Now, I have never used Python, so I have no idea what's going on here. Does anybody know what's going on?

Output of lldb after putting python310.dll in directory

EDIT: I fixed the problem. Let me show you how to get LLDB to work on Windows:

1. Download LLDB
2. Get Python 10
3. If Set path symbols for PYTHONPATH (module directory) and PYTHONHOME (Python root directory), while you’re here you can…
4. Set LLDB_USE_NATIVE_PDB_READER to 1 and…
5. Set LLDB_LIBS_SEARCH_PATH to the Visual Studio DIA SDK libs directory.

I'm trying to do (somewhat) incremental compilation, and in doing so I'm compiling separate classes as separate files. In the following example, I have a file that contains the main function and attempts to allocate and call a constructor on "class" External, which is located in a separate file:

; main.ll
%External = type opaque

declare void @External_init(%External* %this)

define i32 @main() {
	%0 = alloca %External
	call void @External_init(%0)

	ret i32 0
}

And the other file:

; External.ll
%External = type { i32 }

define void @External_init(%External* %this) {
	ret void
}

I'm trying to combine the files using llvm-link like so:

llvm-link -S main.ll External.ll

Which results in:

        %0 = alloca %External
                    ^
llvm-link: error:  loading file 'main.ll'

I'm generating the llvm IR code by hand, and order of files provided to llvm-link doesn't seem to matter, I'd expect the opaque declaration to be replaced by the actual implementation in External.ll

Is it somehow possible to achieve this? If possible I would prefer not to move alloc in External.ll or generate all code in a single file.

I'm evaluating LLVM for feasibility of implementing my language runtime, and the only blocker seems to be implementing virtual threads (a la Java Project Loom). Those are threads that run on the normal OS thread stack, but can be suspended (with their sequence of frames copied off to the heap) and then resumed back on (same or different) carrier thread, i.e. copied back onto the stack.

The thing is, LLVM documentation concerning stack handling seems very sparse.

I've read about LLVM coroutines but it seems to do too much and be overly complex. It also seems to handle only one activation frame:

In addition to the function stack frame...

there is an additional region of storage that contains objects that keep the coroutine state when a coroutine is suspended

The coroutine frame is maintained in a fixed-size buffer

I don't need LLVM to control where the stack frames are stored or when they're freed. I just need two simple operations:

• move the top N activation frames (N >= 1) to a specified location in the heap

• copy N activation frames from heap to the top of current thread's stack

Is such a thing possible in LLVM?

Thank you.

Any idea on how to learn about compiler design? and llvm ?

Hey all,

I've been trying to unbundle single instruction out of the following packet:

bundle {

i1;

i2;

i3;

}

So, the "bundle" marks the start of the bundle (it has UID) and i1, i2 and i3 are instructions making the bundle. I want to move i1 out of the bundle and for that I use unbundleWithSucc method because i1 is the first instruction and should have only successors by my understanding, but when I do that I get:

bundle {

i1;

}

i2 {

i3;

}

Which seems incorrect, because instead of moving the instruction and keeping the marker "bundle" for other two instructions, it forms a new bundle with just that one instruction and other two remain in the structure which seems incorrect since it needs to have the "bundle" marker.
Then, I realized that i1 also a predecessor and that is "bundle" marker. So, when I try to use unbundleWithSucc I get this structure:

bundle;

i1;

i2 {

i3;

}

Which also seems incorrect.
Has any of you dealt with the unbundling and are familiar with this concept?

Not sure if there's restrictions on cross-posting, but my original question is here: https://www.reddit.com/r/MacOS/comments/1aph5zp/lldb_on_sonomaonintel_not_working/

For any Apple Developers, it's the same issue as described here: https://developer.apple.com/forums/thread/742785?page=1#779795022

Hoping someone can assist. Thank you,

​

I was investigating a weird performance difference between clang and gcc, the code generated by gcc is 2x faster. Code in question:

// bs.c
// gcc -O2 -c bs.c -O build/bs-gcc.o
// clang -O2 -c bs.c -O build/bs-clang.o
#include "stddef.h"
size_t binary_search(int target, const int *array, size_t n) {
  size_t lower = 0;
  while (n > 1) {
    size_t middle = n / 2;
    if (target >= array[lower + middle])
      lower += middle;
    n -= middle;
  }
  return lower;
}

unscientific benchmark code

// bs.cc
// clang++ -O2 bs2.cc build/bs-gcc.o -o build/bs2-gcc 
// clang++ -O2 bs2.cc build/bs-clang.o -o build/bs2-clang 
#include <chrono>
#include <iostream>
#include <vector>

extern "C" {
size_t binary_search(int target, const int *array, size_t n);
}

int main() {
  srand(123);
  constexpr int N = 1000000;
  std::vector<int> v;
  for (int i = 0; i < N; i++)
    v.push_back(i);

  for (int k = 0; k < 10; k++) {
    auto start = std::chrono::high_resolution_clock::now();
    for (int i = 0; i < N; i++) {
      size_t index = rand() % N;
      binary_search(i, v.data(), v.size());
    }
    auto end = std::chrono::high_resolution_clock::now();
    printf("%ld\n",
           std::chrono::duration_cast<std::chrono::microseconds>(end - start)
               .count());
  }

  return 0;
}

On my laptop (i9 12900HK) pinned on CPU core 0 (performance core, alder lake architecture), the average time for gcc is around 20k, while that for clang is around 40k. However, when checked using llvm-mca with -mcpu=alderlake, it says the assembly produced by clang is much faster, with 410 total cycles, while the assembly produced by gcc is much slower with 1003 cycles, which is exactly the opposite of what I benchmarked. I wonder if I am misunderstanding llvm-mca or something? I am using gcc 12 and LLVM 17, but from my testing the behavior is the same with older version as well with basically the same assembly.

I'm diving into the world of assembly language and LLVM IR, and I'm curious if anyone knows of any methods or tools that can facilitate the conversion of x86 or ARM assembly code to LLVM IR. Any insights, experiences, or recommendations would be super helpful for my current project. Thanks a bunch!

Would I have any problems due to licensing terms, if I extract C from LLVM by rewriting it in Rust (why? I like the complexity, but I will get more and more serious as I see that the project is worthwhile) for a front-end I have designed these last years?

Since it is part of my strategy to leverage the backend of an experienced language instead of making one from scratch.

Newbie question here, but at the end of the day, does all llvm based have almost the same performance?

If every language is converted into an IR, and the optimizations occur at the IR compilation level, does this means that the front end language almost doesn’t matter?

I used to program using Fortran, which was known as a number cruncher. The specific optimizations that exist for working with some math problems at the compiler level doesn’t exist for a Fortran llvm based compiler, do they?

Would this mean that the classic compiler would be better fit for the problems that Fortran was designed to address than the llvm one?

Hey everyone! For context. I did my undergrad at Georgia Tech, and there I TAed for CS 2110: Intro. Computer Architecture. I liked how the course was organized. We start by building gates out of transistors, then building combinational logic, then sequential logic, which we use to build a datapath which we program in Assembly. The last part of the course is on C, but the connection between it and the earlier parts is weak. No compiler exists for the Assembly language we use, so we have to use ARM or x86 instead. This means students don't see how constructs in C can be lowered to Assembly.

My professor wanted to fix this, and I took him up on the opportunity. Sadly, we can't incorporate my work into the course for logistical reasons, so we open-sourced it instead: https://github.com/lc-3-2. It has a fork of LLVM with a backend for the LC-3.2, which is a version of the LC-3 architecture we use modified to have byte-addressibility and 32-bit words. It also has a basic simulator for the architecture, and a rudimentary C library.

It would be nice to have a (good) compiler to the LC-3, but I don't think LLVM supports targets that are not byte-addressable. The LC-3b (https://users.ece.utexas.edu/~patt/19s.460n/handouts/appA.pdf) might be an easier target. A lot of the code could be reused - the LC-3.2 is based off the LC-3b. What do you think?

I found the stable instruction sets yet can't find any additional info on them, which one does x64 fall under? Or can I just pass "x64" to "LLVM_TARGETS_TO_BUILD" and magic will happen? I Only want to compile what is needed for the target.

The list I found; AArch64, AMDGPU, ARM, AVR, BPF, Hexagon, Lanai, Mips, MSP430, NVPTX, PowerPC, RISCV, Sparc, SystemZ, WebAssembly, X86, XCore.

I'm working on my own toy LLVM project, and I'm trying to understand why the outputted LLVM from translating a C program sometimes outputs global identifiers 1) as a 'string' (i.e. surrounded with "" and 2) prefixes the name with '\01'.

It seems to be parsed fine by LLVM, and also seems to link to the same old fwrite, so I'm hoping somebody could explain why this happens and for what purpose, as it seems completely unnecessary.

I'm using the https://llvm.org/docs/CommandLine.html parser and wonder if there's a way to handle some variadic arguments.

For example, program run -- hello -option1 --xx where ^^^^^^^^^^^^^^^^^^^^^ would just be handled as a string or a list that I can use and it's not checked by the parser.

So I followed the Kaleidoscope tutorial and made the language. But I have now got no idea to like how to make an imperative and useful programming language frontend. I tried to make one, again from the beginning (I targeted Lua), but it went really really messy. I couldn't think of "how to actually implement the thing", Is there some resources I can go through to make one. I want to make one useful language.

Hey, I'm relatively new in LLVM community and I've just bumped into a part with hardware loops, but I'm not sure how to understand it?

Hi. I compiled GTest with clang (+ninja+cmake) and now I'm trying to link my own project to GTest and it results in mismatch detected for 'RuntimeLibrary'. My project is dynamic debug , GTest is static debug. I've had it on MSVC and resolved it with "/MT". But clang does not react to "-MT"!

Firstly, have somebody worked with Gtest+Clang on Windows before? Am I missing something?

Secondly, here's a snippet from GTest building log (redacted):

[4/8] clang -O0 -g -Xclang -gcodeview -D_DEBUG -D_MT -Xclang --dependent-lib=msvcrtd -DGTEST_HAS_PTHREAD=0 -fexceptions -W -MD -MT gtest-all.cc.obj -MF gtest-all.cc.obj.d -o gtest-all.cc.obj -c gtest-all.cc

[7/8] llvm-ar qc gtest_main.lib gtest_main.cc.obj && llvm-ar gtest_main.lib

Snippet from my project building log (redacted):

[9/15] clang -O0 -g -Xclang -gcodeview -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -std=gnu++14 -MD -MT test.cpp.obj -MF test.cpp.obj.d -o test.cpp.obj -c test.cpp

[10/15] clang -fuse-ld=lld-link -nostartfiles -nostdlib -O0 -g -Xclang -gcodeview -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -Xlinker /subsystem:console test.cpp.obj -o devtemplate_test.exe -Xlinker /MANIFEST:EMBED -Xlinker /implib:devtemplate_test.lib -Xlinker /pdb:devtemplate_test.pdb -Xlinker /version:0.0   libdevtemplate.lib  gtest.lib -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames

Those are all essentially the same "-MD -MT" flags in both of them, but for some reason clang treats one as StaticDebug and other as DynamicDebug. Why? How can I fix it? LLVM should be able to link to its own .lib files, right?

built LLVM on windows 10, based on these instructions with VS2022(latest)

https://llvm.org/docs/CMake.html

1. git clone https://github.com/llvm/llvm-project
2. cd llvm-project
3. git checkout llvmorg-17.0.6
4. cd ..
5. mkdir _build
6. cd _build
7. cmake -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=D:\projects\llvm_dev\_install -DLLVM_TARGETS_TO_BUILD=X86 ..\llvm-project\llvm
8. cmake --build .
9. cmake --build . --target install

builds without errors, clang++.exe and others run etc. so the build seems ok

this is the files-tree in my _install folder after building:

• tree: https://pastebin.com/rXJScrSa
• flat: https://pastebin.com/xriB7v8j

then i've added the sample CMakeLists.txt from here https://llvm.org/docs/CMake.html#embedding-llvm-in-your-project

added set (CMAKE_CXX_STANDARD 17)

and extende the line llvm_map_components_to_libnames with orcjit jitlink

​

cmake_minimum_required(VERSION 3.20.0)
project(llvm-orc-jit)

set (CMAKE_CXX_STANDARD 17)

find_package(LLVM REQUIRED CONFIG)

message(STATUS "Found LLVM ${LLVM_PACKAGE_VERSION}")
message(STATUS "Using LLVMConfig.cmake in: ${LLVM_DIR}")

# Set your project compile flags.
# E.g. if using the C++ header files
# you will need to enable C++11 support
# for your compiler.

include_directories(${LLVM_INCLUDE_DIRS})
separate_arguments(LLVM_DEFINITIONS_LIST NATIVE_COMMAND ${LLVM_DEFINITIONS})
add_definitions(${LLVM_DEFINITIONS_LIST})

# Now build our tools
add_executable(llvm-orc-jit main.cc jit.h ccompiler.h)

# Find the libraries that correspond to the LLVM components
# that we wish to use
#llvm_map_components_to_libnames(llvm_libs support core irreader)
llvm_map_components_to_libnames(llvm_libs support core orcjit jitlink)

# Link against LLVM libraries
target_link_libraries(llvm-orc-jit ${llvm_libs})

i think im missing integrating clang in my CMakeLists.txt but can find a good example how to do it - instead of doing all the include/libs folder setup on my own in CMake - the deprecated old way

​

but i still get some linker errors with my sample code - and i can't find the correct libs or something else is still missing

​

the are my linker errors in my small example (reduced my real code down to this testing code) - just for understanding the linking problem

​

#include <clang/Basic/Diagnostic.h>
#include <clang/Frontend/TextDiagnosticPrinter.h>
#include <llvm/Support/raw_ostream.h>

#include <memory>

int main()
{
    auto DO = llvm::IntrusiveRefCntPtr<clang::DiagnosticOptions>(new clang::DiagnosticOptions());
    DO->ShowColors = 1;

    // Setup stderr custom diagnostic consumer.
    auto DC = std::make_unique<clang::TextDiagnosticPrinter>(llvm::errs(), DO.get());

    // Create custom diagnostics engine.
    // The engine will NOT take ownership of the DiagnosticConsumer object.
    auto DE = std::make_unique<clang::DiagnosticsEngine>(
        nullptr /* DiagnosticIDs */, std::move(DO), DC.get(),
        false /* own DiagnosticConsumer */);
}

​

2>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::DiagnosticsEngine::DiagnosticsEngine(class llvm::IntrusiveRefCntPtr<class clang::DiagnosticIDs>,class llvm::IntrusiveRefCntPtr<class clang::DiagnosticOptions>,class clang::DiagnosticConsumer *,bool)" (??0DiagnosticsEngine@clang@@QEAA@V?$IntrusiveRefCntPtr@VDiagnosticIDs@clang@@@llvm@@V?$IntrusiveRefCntPtr@VDiagnosticOptions@clang@@@3@PEAVDiagnosticConsumer@1@_N@Z) referenced in function "class std::unique_ptr<class clang::DiagnosticsEngine,struct std::default_delete<class clang::DiagnosticsEngine> > __cdecl std::make_unique<class clang::DiagnosticsEngine,std::nullptr_t,class llvm::IntrusiveRefCntPtr<class clang::DiagnosticOptions>,class clang::TextDiagnosticPrinter *,bool,0>(std::nullptr_t &&,class llvm::IntrusiveRefCntPtr<class clang::DiagnosticOptions> &&,class clang::TextDiagnosticPrinter * &&,bool &&)" (??$make_unique@VDiagnosticsEngine@clang@@$$TV?$IntrusiveRefCntPtr@VDiagnosticOptions@clang@@@llvm@@PEAVTextDiagnosticPrinter@2@_N$0A@@std@@YA?AV?$unique_ptr@VDiagnosticsEngine@clang@@U?$default_delete@VDiagnosticsEngine@clang@@@std@@@0@$$QEA$$T$$QEAV?$IntrusiveRefCntPtr@VDiagnosticOptions@clang@@@llvm@@$$QEAPEAVTextDiagnosticPrinter@clang@@$$QEA_N@Z)
2>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::DiagnosticsEngine::~DiagnosticsEngine(void)" (??1DiagnosticsEngine@clang@@QEAA@XZ) referenced in function "public: void * __cdecl clang::DiagnosticsEngine::`scalar deleting destructor'(unsigned int)" (??_GDiagnosticsEngine@clang@@QEAAPEAXI@Z)
2>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::TextDiagnosticPrinter::TextDiagnosticPrinter(class llvm::raw_ostream &,class clang::DiagnosticOptions *,bool)" (??0TextDiagnosticPrinter@clang@@QEAA@AEAVraw_ostream@llvm@@PEAVDiagnosticOptions@1@_N@Z) referenced in function "class std::unique_ptr<class clang::TextDiagnosticPrinter,struct std::default_delete<class clang::TextDiagnosticPrinter> > __cdecl std::make_unique<class clang::TextDiagnosticPrinter,class llvm::raw_fd_ostream &,class clang::DiagnosticOptions *,0>(class llvm::raw_fd_ostream &,class clang::DiagnosticOptions * &&)" (??$make_unique@VTextDiagnosticPrinter@clang@@AEAVraw_fd_ostream@llvm@@PEAVDiagnosticOptions@2@$0A@@std@@YA?AV?$unique_ptr@VTextDiagnosticPrinter@clang@@U?$default_delete@VTextDiagnosticPrinter@clang@@@std@@@0@AEAVraw_fd_ostream@llvm@@$$QEAPEAVDiagnosticOptions@clang@@@Z)

these are all my linker errors in the bigger example

​

3>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::DiagnosticsEngine::DiagnosticsEngine(class llvm::IntrusiveRefCntPtr<class clang::DiagnosticIDs>,class llvm::IntrusiveRefCntPtr<class clang::DiagnosticOptions>,class clang::DiagnosticConsumer *,bool)" (??0DiagnosticsEngine@clang@@QEAA@V?$IntrusiveRefCntPtr@VDiagnosticIDs@clang@@@llvm@@V?$IntrusiveRefCntPtr@VDiagnosticOptions@clang@@@3@PEAVDiagnosticConsumer@1@_N@Z) referenced in function "class std::unique_ptr<class clang::DiagnosticsEngine,struct std::default_delete<class clang::DiagnosticsEngine> > __cdecl std::make_unique<class clang::DiagnosticsEngine,std::nullptr_t,class llvm::IntrusiveRefCntPtr<class clang::DiagnosticOptions>,class clang::DiagnosticConsumer *,bool,0>(std::nullptr_t &&,class llvm::IntrusiveRefCntPtr<class clang::DiagnosticOptions> &&,class clang::DiagnosticConsumer * &&,bool &&)" (??$make_unique@VDiagnosticsEngine@clang@@$$TV?$IntrusiveRefCntPtr@VDiagnosticOptions@clang@@@llvm@@PEAVDiagnosticConsumer@2@_N$0A@@std@@YA?AV?$unique_ptr@VDiagnosticsEngine@clang@@U?$default_delete@VDiagnosticsEngine@clang@@@std@@@0@$$QEA$$T$$QEAV?$IntrusiveRefCntPtr@VDiagnosticOptions@clang@@@llvm@@$$QEAPEAVDiagnosticConsumer@clang@@$$QEA_N@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::DiagnosticsEngine::~DiagnosticsEngine(void)" (??1DiagnosticsEngine@clang@@QEAA@XZ) referenced in function "public: void * __cdecl clang::DiagnosticsEngine::`scalar deleting destructor'(unsigned int)" (??_GDiagnosticsEngine@clang@@QEAAPEAXI@Z)
3>main.obj : error LNK2019: unresolved external symbol "private: void __cdecl clang::APValue::DestroyDataAndMakeUninit(void)" (?DestroyDataAndMakeUninit@APValue@clang@@AEAAXXZ) referenced in function "public: __cdecl clang::APValue::~APValue(void)" (??1APValue@clang@@QEAA@XZ)
3>main.obj : error LNK2019: unresolved external symbol "public: virtual __cdecl clang::CodeGenAction::~CodeGenAction(void)" (??1CodeGenAction@clang@@UEAA@XZ) referenced in function "public: virtual __cdecl clang::EmitLLVMOnlyAction::~EmitLLVMOnlyAction(void)" (??1EmitLLVMOnlyAction@clang@@UEAA@XZ)
3>main.obj : error LNK2019: unresolved external symbol "public: class std::unique_ptr<class llvm::Module,struct std::default_delete<class llvm::Module> > __cdecl clang::CodeGenAction::takeModule(void)" (?takeModule@CodeGenAction@clang@@QEAA?AV?$unique_ptr@VModule@llvm@@U?$default_delete@VModule@llvm@@@std@@@std@@XZ) referenced in function "public: class llvm::Expected<struct cc::CCompiler::CompileResult> __cdecl cc::CCompiler::compile(char const *)const " (?compile@CCompiler@cc@@QEBA?AV?$Expected@UCompileResult@CCompiler@cc@@@llvm@@PEBD@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: class llvm::LLVMContext * __cdecl clang::CodeGenAction::takeLLVMContext(void)" (?takeLLVMContext@CodeGenAction@clang@@QEAAPEAVLLVMContext@llvm@@XZ) referenced in function "public: class llvm::Expected<struct cc::CCompiler::CompileResult> __cdecl cc::CCompiler::compile(char const *)const " (?compile@CCompiler@cc@@QEBA?AV?$Expected@UCompileResult@CCompiler@cc@@@llvm@@PEBD@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::EmitLLVMOnlyAction::EmitLLVMOnlyAction(class llvm::LLVMContext *)" (??0EmitLLVMOnlyAction@clang@@QEAA@PEAVLLVMContext@llvm@@@Z) referenced in function "public: class llvm::Expected<struct cc::CCompiler::CompileResult> __cdecl cc::CCompiler::compile(char const *)const " (?compile@CCompiler@cc@@QEBA?AV?$Expected@UCompileResult@CCompiler@cc@@@llvm@@PEBD@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: static bool __cdecl clang::CompilerInvocation::CreateFromArgs(class clang::CompilerInvocation &,class llvm::ArrayRef<char const *>,class clang::DiagnosticsEngine &,char const *)" (?CreateFromArgs@CompilerInvocation@clang@@SA_NAEAV12@V?$ArrayRef@PEBD@llvm@@AEAVDiagnosticsEngine@2@PEBD@Z) referenced in function "public: class llvm::Expected<struct cc::CCompiler::CompileResult> __cdecl cc::CCompiler::compile(char const *)const " (?compile@CCompiler@cc@@QEBA?AV?$Expected@UCompileResult@CCompiler@cc@@@llvm@@PEBD@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::PCHContainerOperations::PCHContainerOperations(void)" (??0PCHContainerOperations@clang@@QEAA@XZ) referenced in function "void __cdecl std::_Construct_in_place<class clang::PCHContainerOperations>(class clang::PCHContainerOperations &)" (??$_Construct_in_place@VPCHContainerOperations@clang@@$$V@std@@YAXAEAVPCHContainerOperations@clang@@@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::CompilerInstance::CompilerInstance(class std::shared_ptr<class clang::PCHContainerOperations>,class clang::InMemoryModuleCache *)" (??0CompilerInstance@clang@@QEAA@V?$shared_ptr@VPCHContainerOperations@clang@@@std@@PEAVInMemoryModuleCache@1@@Z) referenced in function "public: class llvm::Expected<struct cc::CCompiler::CompileResult> __cdecl cc::CCompiler::compile(char const *)const " (?compile@CCompiler@cc@@QEBA?AV?$Expected@UCompileResult@CCompiler@cc@@@llvm@@PEBD@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: virtual __cdecl clang::CompilerInstance::~CompilerInstance(void)" (??1CompilerInstance@clang@@UEAA@XZ) referenced in function "public: class llvm::Expected<struct cc::CCompiler::CompileResult> __cdecl cc::CCompiler::compile(char const *)const " (?compile@CCompiler@cc@@QEBA?AV?$Expected@UCompileResult@CCompiler@cc@@@llvm@@PEBD@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: bool __cdecl clang::CompilerInstance::ExecuteAction(class clang::FrontendAction &)" (?ExecuteAction@CompilerInstance@clang@@QEAA_NAEAVFrontendAction@2@@Z) referenced in function "public: class llvm::Expected<struct cc::CCompiler::CompileResult> __cdecl cc::CCompiler::compile(char const *)const " (?compile@CCompiler@cc@@QEBA?AV?$Expected@UCompileResult@CCompiler@cc@@@llvm@@PEBD@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: void __cdecl clang::CompilerInstance::createDiagnostics(class clang::DiagnosticConsumer *,bool)" (?createDiagnostics@CompilerInstance@clang@@QEAAXPEAVDiagnosticConsumer@2@_N@Z) referenced in function "public: class llvm::Expected<struct cc::CCompiler::CompileResult> __cdecl cc::CCompiler::compile(char const *)const " (?compile@CCompiler@cc@@QEBA?AV?$Expected@UCompileResult@CCompiler@cc@@@llvm@@PEBD@Z)
3>main.obj : error LNK2019: unresolved external symbol "public: __cdecl clang::TextDiagnosticPrinter::TextDiagnosticPrinter(class llvm::raw_ostream &,class clang::DiagnosticOptions *,bool)" (??0TextDiagnosticPrinter@clang@@QEAA@AEAVraw_ostream@llvm@@PEAVDiagnosticOptions@1@_N@Z) referenced in function "class std::unique_ptr<class clang::TextDiagnosticPrinter,struct std::default_delete<class clang::TextDiagnosticPrinter> > __cdecl std::make_unique<class clang::TextDiagnosticPrinter,class llvm::raw_fd_ostream &,class clang::DiagnosticOptions *,0>(class llvm::raw_fd_ostream &,class clang::DiagnosticOptions * &&)" (??$make_unique@VTextDiagnosticPrinter@clang@@AEAVraw_fd_ostream@llvm@@PEAVDiagnosticOptions@2@$0A@@std@@YA?AV?$unique_ptr@VTextDiagnosticPrinter@clang@@U?$default_delete@VTextDiagnosticPrinter@clang@@@std@@@0@AEAVraw_fd_ostream@llvm@@$$QEAPEAVDiagnosticOptions@clang@@@Z)
3>main.obj : error LNK2019: unresolved external symbol LLVMInitializeX86TargetInfo referenced in function "bool __cdecl llvm::InitializeNativeTarget(void)" (?InitializeNativeTarget@llvm@@YA_NXZ)
3>main.obj : error LNK2019: unresolved external symbol LLVMInitializeX86Target referenced in function "bool __cdecl llvm::InitializeNativeTarget(void)" (?InitializeNativeTarget@llvm@@YA_NXZ)
3>main.obj : error LNK2019: unresolved external symbol LLVMInitializeX86TargetMC referenced in function "bool __cdecl llvm::InitializeNativeTarget(void)" (?InitializeNativeTarget@llvm@@YA_NXZ)
3>main.obj : error LNK2019: unresolved external symbol LLVMInitializeX86AsmPrinter referenced in function "bool __cdecl llvm::InitializeNativeTargetAsmPrinter(void)" (?InitializeNativeTargetAsmPrinter@llvm@@YA_NXZ)