search for: obstacks

...p by another few orders of magnitude (as well as reduce memory usage greatly). The main thing blocking this patch, however, is that someone needs to rewrite bitmap.c/bitmap.h, obstack.c and obstack.h, into C++. They are currently just modified versions of what gcc is using. You can get rid of the obstacks, of course. Using set<u32> or BitVector or something like it will result in a slowdown of mammoth proporations, and about a 10x memory increase. Trust me here, you don't want to use a non-sparse bitmap. BDD's are acceptable, but are about a 2x slowdown. With various optimizations th...

...well as reduce memory usage greatly). > > The main thing blocking this patch, however, is that >someone needs to > rewrite bitmap.c/bitmap.h, obstack.c and obstack.h, into >C++. They > are currently just modified versions of what gcc is >using. > You can get rid of the obstacks, of course. > > Using set<u32> or BitVector or something like it will >result in a > slowdown of mammoth proporations, and about a 10x memory >increase. > Trust me here, you don't want to use a non-sparse >bitmap. > BDD's are acceptable, but are about a 2x...

On May 4, 2004, at 10:36 PM, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: >> I suspect that a large reason that LLVM does worst than a native C >> compiler with the CBE+GCC is that LLVM generates very low-level C >> code, >> and I'm not convinced that GCC is doing a very good job (ie, without >> syntactic loops). > > Yup, this is

> glibc does accept patches...or are you talking about two separate instances of this problem, both in glibc and something else? I originally saw this in a benchmark (which it may be possible to get changed) and only afterward found the glibc idiom. The most recent glibc code is a bit more complicated than I represented below. If you look up obstack.h you can see what’s there now.

On Tue, 4 May 2004, Chris Lattner wrote: > I suspect that a large reason that LLVM does worst than a native C > compiler with the CBE+GCC is that LLVM generates very low-level C code, > and I'm not convinced that GCC is doing a very good job (ie, without > syntactic loops). Yup, this is EXACTLY what is going on. I took this very simple C function: int Array[1000]; void test(int

On Wed, 5 May 2004, Patrick Flanagan wrote: > >> and I'm not convinced that GCC is doing a very good job (ie, without > >> syntactic loops). > > > > Yup, this is EXACTLY what is going on. > > Interesting. Now that you mention it, I do recall thinking the loops > that llvm generated looked a bit different than the gcc loops. I'll go > back and take

On Thu, Jan 21, 2016 at 7:04 PM, Brian Cain via cfe-dev < cfe-dev at lists.llvm.org> wrote: > SuSE Linux Enterprise Server 11SP3 x86_64 > > Looks like I see several failures that weren't in 3.7.1. Is there any way > to tell whether these are regressions vs new-to-3.8.0-but-failing? The > MSan ones were in 3.7.1 but the ThreadPoolTest and the libc++ errors were > not

Hi, as discussed in [1], this series adds a new getprogname module. All it does is providing a getprogname function, much like what is found on e.g. *BSD systems, and using it in gnulib instead of progname. Also, using it explicitly by modules avoids gnulib users the need of either use the progname module (GPL), or to provide program_name (and call set_program_name manually, which is not always

Hi 陈晓宇, > The llvm-gcc front end mingw binary on llvm.org <http://llvm.org> has patched a > lot of *.h files under include directory. But when building llvm-gcc on mingw > myself, there is no header file generated under include directory. So where do > these header files come from? I am concerned for their licenses. if you mean the top level include directory in the llvm-gcc

The llvm-gcc front end mingw binary on llvm.org has patched a lot of *.h files under include directory. But when building llvm-gcc on mingw myself, there is no header file generated under include directory. So where do these header files come from? I am concerned for their licenses. Thanks & Regards -------------- next part -------------- An HTML attachment was scrubbed... URL:

Here's the failing tests for rc2 on SLES11.3 (glibc 2.11, libstdc++4.7). I've done some amount of triaging what some critical elements of the failures are. Unabridged log is attached. Failing Tests (94): LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncIntInt LLVM-Unit :: ExecutionEngine/Orc/OrcJITTests/DummyRPC.TestAsyncVoidBool LLVM-Unit ::

When compile 403.gcc, there are link errors. 1) environment 1.1) OS Linux gnode107 2.6.18-128.el5 #1 SMP Wed Jan 21 10:41:14 EST 2009 x86_64 x86_64 x86_64 GNU/Linux *1.2) The default GCC compiler is * gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for

(cc'ing non-legacy llvm-dev this time; apologies if you get this twice. Please don't reply-all to the first one.) On Tue, Jan 19, 2016 at 3:47 PM, Hans Wennborg <hans at chromium.org> wrote: > Dear testers, > > Start your engines; 3.8.0-rc1 was just tagged from the 3.8 branch at > r258223. (It took a little longer than I'd planned, sorry about that.) > > There

Hi everyone, I've got a problem that I would like some input on. The problem basically boils down to a program that I am compiling, whose source I don't control, doing something like this: p = (char*)0 + n where 'n' is an intptr_t-sized value that the program knows is actually a valid address for a pointer. clang translates this as %p = getelementptr inbounds i8, i8*

Hi, I have just tagged 3.7.1-rc1, so it is ready for testing. As a reminder, when doing regression testing, use the 3.7.0 release as your baseline. Thanks, Tom

Hi, I just tagged 3.9.1-rc2, so testing can begin. There was a bug found in -rc1 before I could send out a release announcement, so I decided to merge the fix and tag -rc2 to save some testing cycles. We can always use more testers, so if you are interested in helping, let me know. Thanks, Tom

Hi, There was one problem in -rc1, so we had to do another release candidate. -rc2 has now been tagged and is ready for testing. -Tom