similar to: [LLVMdev] [cfe-dev] Adding new target for hobby OS

Hi Bjarke, Bjarke Walling wrote: > I see. So you check this value stored in a thread-local variable after > each call? And you lower invoke to a call and branch with regard to > this value? > Yes, that's correct. > What are these sophisticated techniques you are talking about? My time > frame for implementing this is, not unlimited, but fairly long. Less > than a

I have Samba setup as a Domain Controller for the domain AROS-NG. I have a Network Appliance that I was able to get to talk to the Samba PDC and it appears to be happy cause I am able to pull up user accounts from the Samba PDC. I am also able to log into XP using the Samba PDC. The only wierd thing that happens is when I try to access the share from the NetApp I get denied. The Netapp gives

Hi, My name is Krzysztof and currently I'm working on porting nouveau (gallium3d driver + libdrm + drm) to AROS Research OS (http://www.aros.org). I completed a quite successful port of "old" drm (one from libdrm git - now removed) and currently I'm working on drm port from the nouveau kernel tree git. Right now I'm faced with rather peculiar memory allocation/access

Hi Nicolas, On Tue, Mar 3, 2009 at 11:38 AM, Nicolas Geoffray <nicolas.geoffray at lip6.fr> wrote: > > Duncan Sands wrote: >> >> Another possibility, very close you yours and currently used by the vmkit >> project, is to modify all functions so they return two values, the usual >> return value and an additional boolean value indicating whether an >>

Bjarke Walling wrote: > Another option I'm thinking about is creating a runtime that, when > initialized, compiles the DWARF information to native code. It could > create an Instruction Pointer lookup hash table associated with unwind > actions. JIT-compiling the unwinder data, yes. Given that the unwinder data is, basically, the source for a specialized bytecode interpreter I

> /nfs_home/chenwj/llvm-3.1/svn/llvm/tools/clang/lib/Frontend/InitHeaderSearch.cpp:197:1: internal compiler error: in extract_insn, at recog.c:2103 I think that this is a GCC ICE. --Sean Silva On Wed, Sep 12, 2012 at 10:53 PM, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote: > Hi all, > > I think it's Gentoo's bug, but I want to know if anyone has the same

See attachments: config.log Error on command line: llvm[4]: Compiling InitHeaderSearch.cpp for Release+Asserts build /home/jamitch/Downloads/llvm-3.2.src/tools/clang/lib/Frontend/InitHeaderSearch.cpp: In member function ‘void<unnamed>::InitHeaderSearch::AddMinGWCPlusPlusIncludePaths(llvm::StringRef, llvm::StringRef, llvm::StringRef)’:

On Sep 12, 2012, at 8:50 PM, Sean Silva <silvas at purdue.edu> wrote: >> /nfs_home/chenwj/llvm-3.1/svn/llvm/tools/clang/lib/Frontend/InitHeaderSearch.cpp:197:1: internal compiler error: in extract_insn, at recog.c:2103 > > I think that this is a GCC ICE. Yes, very definitely. Jim > > --Sean Silva > > On Wed, Sep 12, 2012 at 10:53 PM, 陳韋任 (Wei-Ren Chen) >

Hi. This is a known gcc bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53670). GCC 4.5 can't compile clang 3.1 On 13 September 2012 06:53, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote: > Hi all, > > I think it's Gentoo's bug, but I want to know if anyone has the same > issue here. I am compiling LLVM trunk on Gentoo (gcc 4.5.2), and I get > error

Hi, I am compiling LLVm with clang and I get the following error: Compiling InitHeaderSearch.cpp for Release+Asserts build InitHeaderSearch.cpp:29:51: error: clang/Config/config.h : InitHeaderSearch.cpp: In member function ‘void<unnamed>::InitHeaderSearch::AddDefaultCIncludePaths(const llvm::Triple&, const clang::HeaderSearchOptions&)’: InitHeaderSearch.cpp:237: error:

Took me a while but I have finally embraced cloud computing and all the benefits. The only thing I have yet to feel comfortable about putting in the cloud is real live Asterisk boxes to be used in production. I know it's being done because as far as I know Twilio is using Amazon for their Asterisk boxes. I have read all the fun articles on building hobby type systems and that's all great.

Hi Sergey, > This is a known gcc bug > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53670). GCC 4.5 can't > compile clang 3.1 are you sure? I built the LLVM/clang-3.1 release binaries for ubuntu 64 bits using gcc-4.5. Ciao, Duncan. > > On 13 September 2012 06:53, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw> wrote: >> Hi all, >> >> I think

Hi Duncan. Probably it depends on exact gcc version and possibly assert/noassert build option. I've got this problem with gcc 4.5.2 on 64-bit Suse (I don't remember whether assertions were enabled). On 17 September 2012 21:12, Duncan Sands <baldrick at free.fr> wrote: > Hi Sergey, > > >> This is a known gcc bug >>

Hi all, I think it's Gentoo's bug, but I want to know if anyone has the same issue here. I am compiling LLVM trunk on Gentoo (gcc 4.5.2), and I get error message below, --- make[4]: Entering directory `/nfs_home/chenwj/llvm-3.1/svn/build/tools/clang/lib/Frontend' llvm[4]: Compiling InitHeaderSearch.cpp for Release+Asserts build

Hi All, I am installing llvm 3.1 and clang from the source on my Mac os x 10.5.8. I got this error in the middle of the compilation process: llvm[4]: Compiling InitHeaderSearch.cpp for Release+Asserts build /Users/georgebaah/llvm3.1/llvm-3.1.src/tools/clang/lib/Frontend/InitHeaderSearch.cpp:29:10: fatal error: 'clang/Config/config.h' file not found #include

Hi Andrew, On Tue, Mar 3, 2009 at 2:40 PM, Andrew Haley <aph at redhat.com> wrote: > JIT-compiling the unwinder data, yes. Given that the unwinder data > is, basically, the source for a specialized bytecode interpreter I > can't see any reason this wouldn't work. I might look into that. It will be a good challenge to understand the EH data in detail and program my own

Hi, Some time ago I posted a patch against Bug 1440 <http://llvm.org/bugs/show_bug.cgi?id=1440> about adding a compiler and target option to the llvm demo page. I didn't get any response when fixing the last problems in the patch. Will anyone take a look at it? The patch adds a compiler option with the choice of clang and llvm-gcc. The source languages C/C++/Obj-C/Obj-C++ are available

Is it too late to include "x86_64-unknown-linux" as a supported toolchain name in clang? We tend to need to hand-patch clang source to find include files properly on our systems, the patch looks something like this (just posting as a guideline, I'm not sure if this is the best approach or not, but it seems to work for us): Index: lib/Frontend/InitHeaderSearch.cpp

Hi Duncan, Hi Bjarke, Duncan Sands wrote: > Take a look at libunwind (http://www.hpl.hp.com/research/linux/libunwind/). > Another possibility, very close you yours and currently used by the vmkit > project, is to modify all functions so they return two values, the usual > return value and an additional boolean value indicating whether an exception > was thrown during the call or

Hi all, Is it possible to build the LLVM tools and libraries as bitcode files? I have managed to compile some software to bitcode files by creating a wrapper around llvm-gcc, llvm-g++ and llvm-ld and some hacking. Using binfmt in Linux you can even execute them directly on the command line. The object format becomes transparent. I tried to compile LLVM itself, but things go wrong with the