similar to: [LLVMdev] LLVM on MinGW

SVN head LLVM and Clang built out of the box for me a week ago on MSYS/ MINGW, using the following files: MinGW-5.1.3.exe MSYS-1.0.10.exe msysDTK-1.0.1.exe bash-3.1-MSYS-1.0.11-1.tar.bz2 bison-2.3-MSYS-1.0.11.tar.bz2 coreutils-5.97-MSYS-1.0.11-snapshot.tar.bz2 flex-2.5.33-MSYS-1.0.11.tar.bz2 gawk-3.1.5-MSYS-1.0.11-snapshot.tar.bz2 regex-0.12-MSYS-1.0.11.tar.bz2 1. install these components 2.

Antony Blakey wrote: > SVN head LLVM and Clang built out of the box for me a week ago on > MSYS/MINGW, using the following files: Ok, I tried to do the same. The compilations stops with the following error message (actually, I got to the same point in my attempt to build LLVM with the MinGW compiler shipped with Cygwin): llvm[1]: Compiling MachineLoopInfo.cpp for Debug build

Hello, Thanks to recent changes in the SVN, I was able to successfully build LLVM under Windows in the following environments: 1. Cygwin; 2. MinGW/MSYS; 3. "gcc -mno-cygwin" (a.k.a MinGW on Cygwin). For 3., I've had to make a few manual changes to the build system. Care is needed because non-Cygwin external commands require Windows paths and Cygwin's make does not like path

Hello, Alain. > I'm starting to play with LLVM today and I've trouble compiling it. > I'm > working under Windows Vista, with the gcc from Cygwin: Oh, this seems to be killer mix :) GCC (at least native mingw32 port) has known problems being running on Vista. > Is LLVM supposed to work with this version of GCC (probably using the > -mno-cygwin option to get a

Hi, I was reading some loop related code and I don’t quite understand an assertion in LoopBase<BlockT, LoopT>::getLoopPredecessor(). /// getLoopPredecessor - If the given loop's header has exactly one unique /// predecessor outside the loop, return it. Otherwise return null. /// This is less strict that the loop "preheader" concept, which requires /// the predecessor to have

Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain situations. Should repetitive basic blocks be removed? I have an example to show the problem. Following is the source code and the CFG is enclosed. int main() { int

Hi, I am writing a loop pass to replace the backedge with an edge from latch to exit. Now I just replace the terminator of latch with another BranchInst, and the loop will not be a loop after my pass. However, it turns out a failure of loopverify after executing my pass: opt: ~/llvm/llvm-trunk/include/llvm/Analysis/LoopInfoImpl.h:297: void llvm::LoopBase<N, M>::verifyLoop() const [with

Hello, I'm starting to play with LLVM today and I've trouble compiling it. I'm working under Windows Vista, with the gcc from Cygwin: gcc (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Is LLVM supposed to work with this version of GCC (probably using the -mno-cygwin option to get a Mingw-like behavior)? The LLVM source tree is from the current SVN trunk. Compilation

On Apr 19, 2012, at 10:43 PM, xiaoming gu <xiaoming.gu at gmail.com> wrote: > Hi, all. I'm using void LoopBase::getExitBlocks (SmallVectorImpl< BlockT * > &ExitBlocks) const to get all > exit blocks for a loop. The problem I find with this API is that it returns repetitive basic blocks in certain > situations. Should repetitive basic blocks be removed? Users

On May 7, 2013, at 8:26 PM, zhiyuan yang <sjtu.yzy at gmail.com> wrote: > Hi, > > I am writing a loop pass to replace the backedge with an edge from latch to exit. > Now I just replace the terminator of latch with another BranchInst, and the loop will not be a loop after my pass. However, it turns out a failure of loopverify after executing my pass: > > opt:

Sorry for forgetting to reply all... It works! Thank you very much! But I also wonder how do you know this function will work while there are no documents noticing that. I try learning LLVM by reading its code, but soon feel lost in so many functions. Just like I have many tools, but don't know which to use and what difference it could make. Is there some better ways to learn LLVM? On Wed,

Alain, > Thanks. However, I'm specifically interested in using the MinGW compiler > shipped with Cygwin (i.e. "gcc -mno-cygwin") and using Cygwin tools > (make, ...). Of course, I could probably install MSYS/MinGW just to > compile LLVM and produce the libraries. The short answer is: don't use cygwin shell with mingw compiler to build LLVM. Reason actually is:

I'm getting a lot of these from TOT make: /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h: In instantiation of 'llvm::LoopInfoBase<llvm::BasicBlock>': /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:886: instantiated from here /Volumes/MacOS9/gcc/llvm/include/llvm/Analysis/LoopInfo.h:573: warning: 'class

Greetings. I have an image I've created with a bunch of chost flags which works on my machine when it comes to native boot. if I take that same image into a vm managed via libvirt, I get kernel panic. I'd assume that something is missing from my vm config, question is what and what I can do about it? here is the flags part of lscpu in native and vm: https://dpaste.com/3TR8QJ5G8 and the

Does a comprehensive set of instructions on how to compile Libvirt on a Microsoft Vista platform exist? Has this ever been accomplished? I would very much appreciate input from persons who can give me confidence that a Windows client application can be developed on top of Libviet that connects to a QEMU system on an Ubuntu server. The Libvirt Windows Support page

Hi Ady, Would it work if we removed "ifdef EFI_BUILD" condition and just add -mno-red-zone for all x86_64 builds? If not, do you have any ideas how to pass this flag? This could work, because the patch is adding the -mno-red-zone flag only for x86_64 builds, which are only used in the form of the efi64 target. The efi32 and bios targets are both 32-bit. BTW. I also tried 6.04-pre1 and

Hi, i get error after using a data.frame with subset for "sqlSave". What can i do ? It seems that lines like this in a data.frame structure are after subset deleted and cause the error ? - attr(*, "variable.labels")= Named chr "CUSID" "Welle" "Arbeitgeberfavorit1" "Aktuelle Bewerbungssituation" ... ..- attr(*, "names")=

Hello, Could I please ask you for help? I opened a case in GCC Bugzilla and got reply that -fpie have to be used to get it compiled. Now it fails for me with: x86_64-pc-linux-gnu-gcc -o ssh ssh.o readconf.o clientloop.o sshtty.o sshconnect.o sshconnect1.o sshconnect2.o mux.o roaming_common.o roaming_client.o -L. -Lopenbsd-compat/ -flto=4 -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,-flto -O2

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I did a cvsup for RELENG_7 earlier today. # uname -a FreeBSD polo.example.org 7.1-STABLE FreeBSD 7.1-STABLE #8: Sat Apr 11 18:50:17 EDT 2009 dan@polo.example.org:/usr/obj/usr/src/sys/PHENOM amd64 No idea what went wrong here. Clues please. cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g - -Wall -Wredundant-decls

Hi all, clang -O0 currently differs from -O1 and higher in passing down -mrelax-all. When compiling assembler files, this results in conditional jumps using the relaxed forms, which is surprising. Based on the discussion on IRC, I did a llvm/clang release build with -O0 for OPTIMIZER and -O0 -mno-relax-all. Result is: -O0 (-mrelax-all) 68m27.893s 254m19.920s 1m45.720s -O0 -mno-relax-all