similar to: [LLVMdev] Cross-Compiling libc++ using newlib/Clang based Toolchain.

Hi List, As i m new to this list. i have some issue with my Samba PDC. Main problem is user's roaming profile is not working. NTUSER.DAT --- DENY_WRITE. this is coming . can not load you profile . loading default profile....... Please guide me is there any changes has to made..... Here is my smb.conf file. Version 2.2 OS Redhat 9 [global] workgroup = LK netbios name = HOBBES

Hi, We don't normally do X.Y.2 releases, but there has been some interest in getting a 5.0.2 release out with the Spectre mitigations included, so I am proposing the following schedule for a 5.0.2 release: LLVM 5.0.2 -rc1 Mon Mar 19 -final Mon Mar 26 To keep things easy for testers, 5.0.2 will be for Spectre related fixes only and won't be opened up for general bugs. And here is

I've been running Tinc on my routers for several years. I thought I'd do an integration of tinc with gui in Tomato firmware because I find it useful. It's been working well for me, but I'm sure there's there's a bug or two, or something I've overlooked. Let me know of anything and I'll correct it in a future release. I created a tutorial for Tomato users here.

stubdom: prevent newlib from emiting cli/sti in longjmp Also fix build dependencies and cleanup. Signed-off-by: Samuel Thibault <samuel.thibault@eu.citrix.com> diff -r b320cfe1f10f stubdom/Makefile --- a/stubdom/Makefile Thu Jun 05 13:04:07 2008 +0100 +++ b/stubdom/Makefile Fri Jun 06 16:00:35 2008 +0100 @@ -23,9 +23,11 @@ ifeq ($(GNU_TARGET_ARCH), i686) TARGET_CFLAGS=

Does anyone on this list have experience with newlib? I'm thinking of porting newlib to the COM32 environment, rather than trying to hack my own mini-libc. I just wondered if anyone had any idea of how well that would be likely to work, and/or how well newlib works from a code size standpoint... -hpa

I'd be happy to transfer my code and a brain dump on where I was intended to go with it to anyone who'd be willing to take over the effort. The bottom line is that I just don't have time, nor do I expect to have any time during this year. -hpa

Hi Reid, I'll write a separate post about the intrinsics, but just a quick note about the CFLAGS issue. Reid Spencer kirjoitti: > On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote: >> Another related thing is that even when I defined -emit-llvm in >> what I thought would be a global CFLAGS for all of newlib, it did >> not get propagated to all subdirectories.

Hi Pertti, On Thu, 2006-11-09 at 18:41 +0200, Pertti Kellomäki wrote: > Hi Reid, > > I'll write a separate post about the intrinsics, but just > a quick note about the CFLAGS issue. Okay. > > Reid Spencer kirjoitti: > > On Thu, 2006-11-09 at 15:29 +0200, Pertti Kellomäki wrote: > >> Another related thing is that even when I defined -emit-llvm in >

Reid Spencer kirjoitti: > So, now I'm not sure what you're talking about. Is > libgloss part of newlib? If so, please note that it is not llvm-gcc's > job to pass CFLAGS down. That would be a bug in the newlib makefiles. :) Sorry for being obtuse. Yes, if there indeed is a bug, it is in the newlib build system. I was trying to compile newlib with llvm-gcc. The need for

On Thu, 9 Nov 2006, [ISO-8859-1] Pertti Kellom�ki wrote: > to identify that we are compiling to LLVM byte code. If there is > one, I'd be happy to hear it, but if not, then it might be a good > idea to define __LLVM__ or something like that in (by) llvm-gcc. llvm-gcc defines __llvm__. -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Thu, 9 Nov 2006, Reid Spencer wrote: >> Currently there are a few intrinsics that have >> to do with libc, like llvm.memcpy and llvm.memmove. However, I >> would personally prefer less pollution in the intrinsic name space, >> so I would propose naming the intrinsics with a llvm.libc prefix, >> e.g. llvm.libc.open and so forth. Any strong opinions on this? >

Chris Lattner kirjoitti: > There isn't any really good reason to have an llvm intrinsic for write, > just leave 'write' as an external function. So is the opportunity for inlining the only reason for e.g. the llvm.memcpy intrinsic? -- Pertti

On Thu, 9 Nov 2006, Markus F.X.J. Oberhumer wrote: > > llvm-gcc defines __llvm__. > Could we add some more detailed version information to the frontend, > e.g. such as a predefined -D__llvm_bytecode_version__=6 ? Why do you need this? -Chris -- http://nondot.org/sabre/ http://llvm.org/

Chris Lattner kirjoitti: > llvm-gcc defines __llvm__. Thanks. I thought I tried it, but apparently not. -- Pertti

Pertti Kellomäki wrote: > Chris Lattner kirjoitti: > >>llvm-gcc defines __llvm__. > > > Thanks. I thought I tried it, but apparently not. Try: <path-to-llvm-gcc-install>/llvm-cpp -dM /dev/null | grep -y llvm llvm-cpp should be installed if you built the gcc frontend. Mine reports __llvm__. BTW: Would be nice if the frontend defined a manifest constant if it is

On Thu, 9 Nov 2006, Scott Michel wrote: > BTW: Would be nice if the frontend defined a manifest constant if it is > generating byte code vice generating native. But that's a refinement for > another day... Why? As an end user, I'd be very unhappy if I got different code from -emit-llvm + llc then from normal llvm-gcc. -Chris -- http://nondot.org/sabre/ http://llvm.org/

Chris Lattner wrote: > On Thu, 9 Nov 2006, Scott Michel wrote: > >> BTW: Would be nice if the frontend defined a manifest constant if it is >> generating byte code vice generating native. But that's a refinement for >> another day... > > > Why? As an end user, I'd be very unhappy if I got different code from > -emit-llvm + llc then from normal

I made the switch to llvm3.3, and encountered a flt_rounds I'm using a soft float architecture and hopefully people have some ideas on how to help: I received: i32 = flt_rounds "Do not know how to promote this operator!" I currently do not have any custom setting for the FLT_ROUNDS_ I'd like to just replace the FLT_ROUNDS_ with a "1" value. Any thoughts on how

Hello, I have noticed that Peter wanted to port newlib to syslinux project some time ago. It seems that the porting was not finished. Peter mentioned (http://syslinux.zytor.com/archives/2004-February/003168.html) that sucj job would require a lot of efforts. At the same time newlib is usually regarded as a "highly portable C-library". I am wondering what are the major

Pertti Kellomäki wrote: > John Criswell kirjoitti: > >> So, let me see if I understand this right: >> >> First, it sounds like you're programming on the bare processor, so your >> I/O instructions are either special processor instructions or volatile >> loads/stores to special memory locations. >> > > Yes. In more detail, instruction