similar to: [LLVMdev] Building LLVM under Mingw. Part I: tools-only

BTW: I've also had to make this change when building tools. (I'm building right now and noticed that it doesn't come up anymore, maybe someone checked it in in the last week or so) On Sat, 29 Apr 2006, Anton Korobeynikov wrote: > Hello, Jeff. > > You wrote Saturday, April 29, 2006, 10:45:02 PM: > > JC> Yes, I know mingw doesn't support dbghelp. I can still rant

Hello, Jeff. You wrote Saturday, April 29, 2006, 10:45:02 PM: JC> Yes, I know mingw doesn't support dbghelp. I can still rant about it :) ;) Well. Maybe this library will be included in some next versions of mingw's win32api package. Anyway, we can make such library just "on-fly" from the corresponding .dll. JC> This is what's already there. What changed? Maybe

Hey Evan, At the point of the instructions you suggested I step through, X86ISelLowering has this state: - this 0x00000000005fe728 {VarArgsFrameIndex=-842150451 RegSaveFrameIndex=-842150451 VarArgsGPOffset=3452816845 ...} llvm::X86TargetLowering * const + llvm::TargetLowering {TM={...} TD=0x00000000008edac0

On Wed, Nov 28, 2018 at 6:25 PM Chris Lattner via cfe-dev < cfe-dev at lists.llvm.org> wrote: > Generally no IMO, because the cases that produce optional are not obvious. > Just to say, +1 from me too. > > > * Can we use auto in c++14 lambda arguments with llvm::find_if(C, > [](const auto& i) { ... }) for example? > > * We need to use auto for structured

I'm not advocating AAA. However this is a proposal for more modern thinking regarding the permissiveness of auto in LLVM codebases. Currently the rule on the use of auto is here: https://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable It is quite strict. It allows the use of auto for * lambdas * iterators because they are long to type * casts to

Hello, Everyone. This is just brief description on building llvm-gcc4 with mingw32. It's definitely non error-free and contains many "hacks", which should be eliminated in the future. 1. Prerequisites We're building in the folowing configuration: 1.1 GCC 3.4.5: gcc -v Reading specs from f:/research/mingw/bin/../lib/gcc/mingw32/3.4.5/specs Configured with:

Builds fine on Linux, but there seems to be a problem building it on Cygwin, will look into this. Aaron ----- Original Message ----- From: Aaron Gray To: LLVM Developers Mailing List Sent: Thursday, June 30, 2005 7:12 PM Subject: [LLVMdev] X86AsmPrinter + MASM and NASM backends I have "refactored" the X86AsmPrinter into a number of files ready for the MASM and NASM

I admit that I am not familiar with Tinc very well but see that Tinc is running their current vpn connections. We have a scenario that has 20 different sites currently and successfully using tinc on openwrt but I am having issues adding an additional site as it will not communicate with the rest. I am not the one that originally setup the system but that person is no longer available. I have

Hi, Is it possible to generate a data dependence graph of llvm assembly file? How can I get the data flow information in X.ll file? Also, in .ll file I see everyline ends with something like this: <type> [#uses=3] What is the significance of this and is it used anyway by the compiler for data dependence analysis. I would be grateful for any help. Regards, Manvi

I have "refactored" the X86AsmPrinter into a number of files ready for the MASM and NASM backends to be added. There is a new namespace llvm::X86 to replace the anomonous namespace as this does not work accross mutiple .h and .cpp files. Other than that everything is pritty straight forward, t may possibly need tweeking though. It has been built under MS VS2003, but I am not sure how

This class has been replaced by the ProcessorsAgent. Signed-off-by: Darryl L. Pierce <dpierce at redhat.com> --- src/Makefile.am | 4 - src/cpu.cpp | 216 ------------------------------------------------------- src/cpu.h | 111 ---------------------------- src/host.cpp | 24 ------ src/host.h | 3 - src/schema.xml | 16 ---- 6 files changed, 0 insertions(+),

On Feb 12, 2008, at 5:26 PM, Chuck Rose III wrote: > Hola LLVMers, > > I’m debugging through some strangeness that I’m seeing on X64 on > windows with LLVM2.2. I had to change the code so that it would > engage the x64 target machine on windows builds, but I’ve otherwise > left LLVM 2.2 alone. The basic idea is that I’ve got a function bar > which is compiled by

Hi Reid, The error still exists. However, looking on the function in Win32/Path.cpp: -------------- void sys::CopyFile(const sys::Path &Dest, const sys::Path &Src) { if (!::CopyFile(Src.c_str(), Dest.c_str(), false)) ThrowError("Can't copy '" + Src.toString() + "' to '" + Dest.toString() + "'"); } -------------- I

Some wheird problem, Target/X86 builds okay now. But there seems to be another problem with the Cygwin build :- make[4]: Entering directory `/usr/build/llvm/lib/Target/SparcV9/ModuloScheduling' llvm[4]: Compiling ModuloSchedulingSuperBlock.cpp for Debug build /usr/src/llvm/lib/Target/SparcV9/ModuloScheduling/ModuloSchedulingSuperBlock.cpp : In member function `virtual bool

> LLVM already includes this: the -indvars pass. It turns things like this: > > int *P = for (...; ... ; ++P) > *P > > to: > > int *P = ... > for (int i = 0; ... ; ++i) > P[i] > > If you're interested in dependence analysis, the next important step is to > start analyzing distance and direction vectors. You can check out

On Fri, 17 Jun 2005, Manvi Agarwal wrote: > Hi Chris, Hi. FYI, it's usually better to email the llvmdev list with generic llvm questions. > Is it possible to get control flow graph of the application with the llvm > infrastructure in terms of basic blocks? Yes, given a BasicBlock*, you can iterate over the pred/succ blocks in the CFG like this: #include

Consistant error building LLVM on Cygwin from CVS :- make[2]: Entering directory `/usr/build/llvm/tools/llc' llvm[2]: Compiling llc.cpp for Debug build llvm[2]: Linking Debug executable llc /usr/build/llvm/Debug/lib/LLVMX86.o(.text+0x30506): In function `_GLOBAL__D__ZN7 6_GLOBAL__N__usr_src_llvm_lib_Target_X86_X86ISelPattern.cpp_9D2164D3_DD38501517X

Hi, Can anyone tell me why CopyFile is the only undefined reference from Path.cpp? --------------- llvm[2]: Linking Debug executable gccld c:/projects/build/MinGW/llvm-1-1/tools/gccld/Debug/gccld.o(.text+0x439): In function `Z15EmitShellScriptPPc': c:/projects/src/llvm-1/llvm/tools/gccld/gccld.cpp:127: undefined reference to `llvm::sys::CopyFile(llvm::sys::Path const&, llvm::sys::Path

No, although its declared in the Path.h file, its actually not in the Path class. Have a look. Not sure why you're still seeing that problem. The same change to Unix/Path.cpp fixed the same problem on Cygwin and Linux. Reid. On Thu, 2004-12-23 at 15:48, Henrik Bach wrote: > Hi Reid, > > The error still exists. However, looking on the function in Win32/Path.cpp: > --------------

But breaks VC++. The problem is, Windows.h defines "CopyFile" as a macro that's either "CopyFileA" or "CopyFileW". Path.h is included before Windows.h, so the declaration has the name "CopyFile" while the definition has "CopyFileA". Instant compilation error. Not sure what the best way to fix it is, but I'll check it in as soon as I