similar to: RFC: LLVM - lld - Add visual studio compatible diagnostics output to lld

Hi, I understand that making lld's error message compatible with MSVC makes it easy to use in IDEs. But at the same time I personally prefer the current style of lld's error message because it's easier to read particularly when filenames or symbol names are long (which is a norm in modern projects). I'd start with experimenting your idea with a small change. I guess that the

Hi, We would like to see that change, too, especially for lld/ELF. Chris, do you have a patch or just looking for help? Best Regards, Igor Kudrin C++ Developer, Access Softek, Inc. ________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> Sent: Friday, February 23, 2018 6:37 AM To: Chris

Hi, I'm still working on this problem by first trying code without the Altivec intrinsics. I'm trying to use the cross compiler on the c code outputted by "llc -march c" and have run into this linker problem (spewed by the cross compiler): Command line : error: L0039: reference to undefined symbol .fopen64 in file /tmp/cc4tgLu5.o Command line : error: L0039: reference to

On Apr 6, 2008, at 11:24 AM, Sunjae Park wrote: > On Sunday 06 April 2008 06:53:06 am Bill Wendling wrote: >> (snip) >> Hi Sunjae, >> >> You'll need to compile llvm-gcc as a cross-compiler to get it to >> accept altivec intrinsics and PPC-specific flags. >> >> -bw > > Thanks, Bill. I was afraid of that. > > Any pointers on how to do

On Sunday 06 April 2008 06:53:06 am Bill Wendling wrote: > (snip) > Hi Sunjae, > > You'll need to compile llvm-gcc as a cross-compiler to get it to > accept altivec intrinsics and PPC-specific flags. > > -bw Thanks, Bill. I was afraid of that. Any pointers on how to do this? I'm able to build llvm-gcc-4.2 x86 natively, but not the powerpc version. Using

I'm trying to compile some large programs with clang on Windows (with a view to compiling to bit code and then running some whole program optimisations on the bit code). Take for example the Python 2.7 interpreter: As is typically the case, the usual build procedure involves running msbuild which invokes the Microsoft compiler. The most obvious procedure would then be to substitute

I think MSBuild isn't capable of re-running cmake and then reloading the project files when CMakeLists.txt changes. It re-runs cmake, but then continues the build with the stale projects. That probably explains the "PipSqueek.cxx doesn't exist" errors. As for the link error, it could also be caused by things like a file rename not getting picked up by MSBuild. The fix is

With VS2013 I found that editing a CMakeLists.txt file caused CMake to be re-run successfully and the build to also continue successfully, but since I switched to VS2015 the CMake re-run occurs - apparently successfully, but more often than not the build failed afterwards from either the IDE and from MSBuild. Since I seldom change the CMakeLists.txt files, I simply do a clean CMake configuration

I'm trying to build LLVM 3.5.1 on Windows, almost successfully; the remaining stumbling block is getting static linking for release builds. The problem is that the .vcxproj is interpreted by msbuild to compile with the /MD option instead of /MT, as detailed in: https://stackoverflow.com/questions/28262372/getting-msbuild-to-use-mt-staticrelease Haven't got any answers on that question,

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

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

On Fri, Jul 10, 2015 at 2:00 AM, Chandler Carruth <chandlerc at google.com> wrote: > This seems more relevant to cfe-dev. > Okay. > > You seem to be struggling with the need to name the binary 'cl.exe'. Last > time I checked, we installed clang-cl.exe under that name in a specialized > director specifically so you can use build systems relying on that name. >

>From my own experience this is what I think happens when building the whole solution through Visual Studio's UI. This also happens for building individual projects. I assume something similar happens when building via the command-line, but I rarely do that, so I can't be certain. 1) Visual Studio/MSBuild (I don't know which, but probably MSBuild) determines the dependency graph of

msbuild is is able to re-run cmake if a CMakeLists.txt changes. CMake adds a special project "ZERO_CHECK" that does this. However, I am not sure it runs when invoking on the individual projects instead of the solution. Try the cmake --build command, which should output the following: > cmake --build . --target opt CMake is re-running because

I was hoping to not have to build LLVM myself, especially on Windows. Can anybody help me with the Windows installer? Failing that, I find the directions for how to compile on Windows hard to follow? Can I build using Cygwin? Regards, Eric On 9/29/14, 8:11 AM, Rafael Auler wrote: > I'm not sure about the Windows installer, but if you build and install > LLVM for Windows from the

Hello Erik, Thank you to work. I have not checked to build them, though, I can tell you some comments, excuse me. * General - Please post patches to cfe-commits and to llvm-commits, too. (IMHO it would not be needed to split articles apart each lists as long as each would be related.) - If you can, please attach files w/o CRLF(dos encodings), or with attached text/plain. - You may

It looks like building ZERO_CHECK first to reconstruct the project files as needed, then running msbuild a second time to do the actual build, has solved the problem. At least, last night's run didn't take the usual two tries. Running msbuild twice is a little bit simpler than running cmake explicitly, the way I have my scripts set up, but I'm sure that would work as well. Thanks

I replaced all instances of "$(Platform)" with "x64" for the x64 .props file and it still fails, so it looks like that guess was wrong as well. Regards, Eric On 9/29/14, 2:11 PM, Eric Mader wrote: > Quoting doesn't seem to make a difference. Strangely, the Win32 > toolset seems to work. (Where "work" means that clang runs and > produces a bunch of

I'm getting compile errors because size_t is getting redefined. My "forced include file" starts with: #if BUILDING_FOR_WINDOWS #define NOMINMAX /* deal with the fact that windef.h also defines BOOL */ #define BOOL WINBOOL #include <windows.h> #include <intrin.h> #undef BOOL #endif Looking at the preprocessor expansion of a typical .cpp file, I see that crtdefs.h

Here are a couple of representative errors. C:\Dev\upstream\gitmono is where I keep my clone. "C:\Dev\upstream\gitmono\wbuild\ALL_BUILD.vcxproj" (Rebuild target) (1) -> "C:\Dev\upstream\gitmono\wbuild\unittests\Support\DynamicLibrary\SecondLib.vcxproj" (default target) (170:2) -> c1xx : fatal error C1083: Cannot open source file: