similar to: [LLVMdev] FreeBSD build broken

Hi again, I wrote: > > I would like to test but the I modigied the configure to make > > unknown = OpenBSD and Unix > > Have you looked at ./config.log. ./configure creates this as it runs > as a trace of the path it took through ./configure. Work backwards > from the end to find out what it didn't like. I remember SourceForge's compile farm has an OpenBSD x86

I'll Check it out.. is it in the CVS or the release yet.. or how do I apply a patch to it... thanks much for the update.. I'll feel better about the whole thing..OpenBSD is really nice with the pro-police stack and would like to see an alternative to the GCC only compiler chain of tools especially as it is based on a somewhat archaic optiminzation backend and procedural stuff is pretty

I just added __OpenBSD__ everywhere __FreeBSD__ was being tested (there were about a dozen places). I suspect we'll have to add one for NetBSD also one day (even DragonflyBSD?). INT8_MAX and friends ought to be declared by <stdint.h>. It is on FreeBSD. Ralph Corderoy wrote: >Hi again, > >I wrote: > > >>>I would like to test but the I modigied the

Hi Josephm > I would like to test but the I modigied the configure to make unknown > = OpenBSD and Unix and go pretty far but it died right after 'supports > mkdir' yes... Could that have been `checking for mkdir...'? > then the next line was 'your system is unsupported'' Have you looked at ./config.log. ./configure creates this as it runs as a trace of the

I would like to test but the I modigied the configure to make unknown = OpenBSD and Unix and go pretty far but it died right after 'supports mkdir' yes... then the next line was 'your system is unsupported'' I have gcc 3.3 on OpenBSD 3.3 pro-police stack compiler... I am only really interested in testing the C/C++ but C primarily for my work. regards, Joseph Altea

Hi Jeremy,   I got some info on that topic from the illumos devs:   > It's a sporadic issue, you're lucky enough to not encounter it on 4.9.5. > > I confirmed in 4.10.2, it happens: > > winbindd.log:  tdb(/tmw-nas-3p/samba/var/lock/gencache.tdb): tdb_open_ex: tdb_mutex_init failed for /tmw-nas-3p/samba/var/lock/gencache.tdb: Device busy > > So either apply OS fix, or

They are all Alpha/PowerPC codegen related. Running /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/dg.exp ... FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/2005-07-12-TwoMallocCalls.ll: NODE: 0x8582a40: i32,ch = CopyFromReg 0x8582980:1, 0x85829c0 Abort trap (core dumped) FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/Alpha/bsr.ll: NODE: 0x85823c0:

I'm getting the following error: ERROR: tcl error sourcing /usr/home/jeffc/llvm/obj/test/site.exp. extra characters after close-quote while executing "set llvmgcc "PATH="/usr/home/jeffc/llvm/obj/Debug/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/jef..." (file "/usr/home/jeffc/llvm/obj/test/site.exp"

FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll: %Y = cast sbyte %SB to uint ; <uint> [#uses=1] %Y = cast sbyte %SB to int ; <int> [#uses=1] %Y = cast sbyte %SB to int ; <int> [#uses=1] %Y = cast ubyte %SB to uint ; <uint> [#uses=1] %Y = cast ubyte %SB to

It doesn't build. llvm-main.cpp doesn't get compiled for some reason: g++40 -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -fno-common -DHAVE_CONFIG_H -DENABLE_LLVM -D__STDC_LIMIT_MACROS -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include -I./../intl

Hi, just chiming in here... Óscar Fuentes wrote: > [...] > > This is a simple guide for using cmake with LLVM: > > http://www.llvm.org/docs/CMake.html > > The makefiles distributed with LLVM have nothing to do with cmake. >From the few times I tried building LLVM with CMake I got the impression that it wasn't completely mature yet (the "TODO" sections in

FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/LoopStrengthReduce/dont_insert_redundant_ops.ll: FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/LoopStrengthReduce/dont_reduce_bytes.ll:

Two unexpected failures are occurring: FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/CodeGen/X86/shift-double.llx: FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll: %Y = cast sbyte %SB to uint ; <uint> [#uses=1] %Y = cast sbyte %SB to int ; <int> [#uses=1] %Y =

No error messages with these failures? Can you look into the output files? Reid. On Sat, 2005-07-30 at 14:04 -0700, Jeff Cohen wrote: > FAIL: > /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/LoopStrengthReduce/dont_insert_redundant_ops.ll: > > > FAIL: > /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/LoopStrengthReduce/dont_reduce_bytes.ll: > > >

The only non-empty output file I can find is ops_after_indvar.ll.out: Instruction does not dominate all uses! %idx = cast int %idx to uint ; <uint> [#uses=1] %tmp. = mul uint %idx, 4 ; <uint> [#uses=1] Instruction does not dominate all uses! %tmp. = mul uint %idx, 4 ; <uint> [#uses=1] %tmp.1 = add uint %P,

Hi Jeff and Morten, I was just wondering if below wisdom is true, why not prefix every solution and project file with VC71 in front of the file name to signal the case that it is only designed for that specific IDE/tool? This gives us room for comming up with other solution and project files for another MS specific IDE/tool independt of each other. Henrik. ----Original Message Follows----

----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfileor directory Date: Thu, 23 Dec 2004 08:05:39 -0800 >Yes, it

It's a possibility, though it would be better to create whole separate trees for different versions of VS. It's not just the project and solutions that need to be kept separate; the object files themselves cannot be mixed between different versions of VS. There's no rush though. Trust me, C/C++ programmers will not rush to adopt Whidbey once it's released. You'd be

I agree completely with you, Jeff. However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk). And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC

I successfully build llvm from cvs using vs2005 and stlport. I also had a couple of issues, but most were due to outdated project files. I also had to implement code for the alloca instruction. On 3/10/07, Jeff Cohen <jeffc at jolt-lang.org> wrote: > > The recent issues concern the head revision, post 1.9. As no one has > ever submitted patches to fix 2005 problems with the 1.9