search for: fetchstag

...ild\ALL_BUILD.vcxproj" (Rebuild target) (1) -> "C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj" (default target) (339:2) -> (Link target) -> Backend.obj : error LNK2019: unresolved external symbol "public: virtual bool __cdecl mca::FetchStage::isReady (void)const " (?isReady at FetchStage@mca@@UEBA_NXZ) referenced in function "public: void __cdecl mca::Backend::run (void)" (?run at Backend@mca@@QEAAXXZ) [C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj] From: Valentin Churavy [mailto:v.chur...

...> (1) -> > > "C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj" > (default target) (339:2) -> > > (Link target) -> > > Backend.obj : error LNK2019: unresolved external symbol "public: > virtual bool __cdecl mca::FetchStage::isReady > > (void)const " (?isReady at FetchStage@mca@@UEBA_NXZ) referenced in > function "public: void __cdecl mca::Backend::run > > (void)" (?run at Backend@mca@@QEAAXXZ) > [C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj] > >...

What kind of missing symbols are you getting? I had to work around dependencies for a Mingw32 build. See https://reviews.llvm.org/D44650 On Wed, May 16, 2018, 13:13 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I have the git monorepo, and Visual Studio 2015. I am finding that > running a build from the command line with msbuild (as a nightly job) > invariably fails on the

..."C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj" >> (default target) (339:2) -> >> >> (Link target) -> >> >> Backend.obj : error LNK2019: unresolved external symbol "public: >> virtual bool __cdecl mca::FetchStage::isReady >> >> (void)const " (?isReady at FetchStage@mca@@UEBA_NXZ) referenced in >> function "public: void __cdecl mca::Backend::run >> >> (void)" (?run at Backend@mca@@QEAAXXZ) >> [C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm...

..."C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj" >> (default target) (339:2) -> >> >> (Link target) -> >> >> Backend.obj : error LNK2019: unresolved external symbol "public: >> virtual bool __cdecl mca::FetchStage::isReady >> >> (void)const " (?isReady at FetchStage@mca@@UEBA_NXZ) referenced >> in function "public: void __cdecl mca::Backend::run >> >> (void)" (?run at Backend@mca@@QEAAXXZ) >> [C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\ll...

...no\wbuild\tools\llvm-mca\llvm-mca.vcxproj" > >> (default target) (339:2) -> > >> > >> (Link target) -> > >> > >> Backend.obj : error LNK2019: unresolved external symbol > "public: > >> virtual bool __cdecl mca::FetchStage::isReady > >> > >> (void)const " (?isReady at FetchStage@mca@@UEBA_NXZ) referenced > >> in function "public: void __cdecl mca::Backend::run > >> > >> (void)" (?run at Backend@mca@@QEAAXXZ) > >> [C:\Dev\upstream\gitm...

..."C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm-mca.vcxproj" >> (default target) (339:2) -> >> >> (Link target) -> >> >> Backend.obj : error LNK2019: unresolved external symbol "public: >> virtual bool __cdecl mca::FetchStage::isReady >> >> (void)const " (?isReady at FetchStage@mca@@UEBA_NXZ) referenced >> in function "public: void __cdecl mca::Backend::run >> >> (void)" (?run at Backend@mca@@QEAAXXZ) >> [C:\Dev\upstream\gitmono\wbuild\tools\llvm-mca\llvm...

I have the git monorepo, and Visual Studio 2015. I am finding that running a build from the command line with msbuild (as a nightly job) invariably fails on the first try, and succeeds on a retry. The first msbuild command looks like this: msbuild ALL_BUILD.vcxproj /p:Configuration="RelWithDebInfo" /m:6 /t:Rebuild This appears to compile everything okay, but invariably fails with

...IR translation, which is necessary to support big endian code correctly. [r332449](https://reviews.llvm.org/rL332449). * The DEBUG macro has been renamed to `LLVM_DEBUG`. [r332240](https://reviews.llvm.org/rL332240). * llvm-mca gained the abstraction of a pipeline stage, and now includes a simple FetchStage. [r332390](https://reviews.llvm.org/rL332390). * SimplifyLibCalls learned to replace locked IO with unlocked IO when this can be proven to be safe. [r332452](https://reviews.llvm.org/rL332452). * The MC Assembler now matches the behaviour of the GNU assembler for comparison operators. [r332215](...