similar to: [LLVMdev] LLVM build fails on Linux x86

gcc 3.4.x builds LLVM incorrectly on x86_64. gcc 4.0 will get you much farther, but the llvm-test regression tests still have massive problems. Zhongxing Xu wrote: > The machine is a Dell workstation with xeon processors. The OS is RHEL > 4 AS x86_64 > gcc version is 3.4.6 > > I checked out the llvm-gcc from svn, configured with > ../llvm-gcc/configure

Already have concerning gcc 3.4: http://llvm.org/bugs/show_bug.cgi?id=1056 As for llvm-test issues, quite frankly I don't know how well they're expected to work on x86_64. No one has jumped in and said they run fine on their x86_64 system. Maybe they're code generator bugs, or maybe they're portability issues for FreeBSD (though I never saw such massive problems with 32-bit

On Jan 9, 2007, at 9:48 PM, Jeff Cohen wrote: > gcc 3.4.x builds LLVM incorrectly on x86_64. > > gcc 4.0 will get you much farther, but the llvm-test regression tests > still have massive problems. Please file bug reports on these. Thanks! Evan > > Zhongxing Xu wrote: >> The machine is a Dell workstation with xeon processors. The OS is >> RHEL >> 4 AS

The machine is a Dell workstation with xeon processors. The OS is RHEL 4 AS x86_64 gcc version is 3.4.6 I checked out the llvm-gcc from svn, configured with ../llvm-gcc/configure --prefix=$HOME/llvm-gcc-install --enable-llvm=$HOME/llvmobj/ --enable-languages=c,c++ --enable-checking --disable-shared --disable-multilib and get the following error message: make

I do all my LLVM stuff on x86_64 without trouble... I have a nightly tester up, and its only getting a few regressions currently, and I think some of those have to do with the radical changes going on in LLVM-land currently, and others with no one having done support for x86-64 in debugging output. (this is at least most of what I've seen, ymmv). Also, for the record, I have found both gcc

Could you provide a list of all tests failing for you? You can just grep the output from make for 'FAILED!'. I've fixed 5 of them so far... 275 to go... Chandler Carruth wrote: > I do all my LLVM stuff on x86_64 without trouble... I have a nightly > tester up, and its only getting a few regressions currently, and I > think some of those have to do with the radical

I get this on Ubuntu Hardy on ia32: llvm[1]: Compiling raw_ostream.cpp for Release build In file included from raw_ostream.cpp:14: /home/regehr/llvm/include/llvm/Support/raw_ostream.h:116: error: ‘llvm::raw_ostream& llvm::raw_ostream::operator<<(size_t)’ cannot be overloaded /home/regehr/llvm/include/llvm/Support/raw_ostream.h:108: error: with ‘llvm::raw_ostream&

Python 2.x works. Thanks Joey. 于 2011/12/25 18:41, Joey 写道: > Which version of Python? > > Looks like the same error I had when trying to use 3.x. You have to > use a 2.x version of Python. > > Joey > > On Sunday, 25 December 2011, Xu Zhongxing <xu_zhong_xing at 163.com > <mailto:xu_zhong_xing at 163.com>> wrote: > > I executed > > > >

Index: include/llvm/ADT/APInt.h =================================================================== --- include/llvm/ADT/APInt.h (revision 55101) +++ include/llvm/ADT/APInt.h (working copy) @@ -20,6 +20,7 @@ #include <cassert> #include <iosfwd> #include <string> +#include <cstring> namespace llvm { class Serializer; -------------- next part -------------- An

Here's a performance testcase for the raw_svector_ostream patch. On my WIndows x64 machine it runs in 1010ms with the current code and in 440ms with the patch applies. Is this OK to commit? 2015-05-02 21:31 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > Following a hint from Duncan in http://llvm.org/pr23395, here is a > revised patch. Rather then introduce the

r244870 (with the change you requested), thanks! I initially placed the virtual function in header since they were one-liners. The coding standards say that an anchor() function should be supplied, which was indeed missing. Other than required anchor function, why should the virtual functions go in the .cpp? Should I move the empty raw_svector_ostream destructor to the .cpp file too as well?

+update diff 2015-05-02 7:38 GMT+03:00 Yaron Keren <yaron.keren at gmail.com>: > I outlined (is that the right > word?) raw_char_ostream::grow, raw_char_ostream::write (both) into > raw_ostream.cpp with less than 10% difference in performance. > > Profiling reveals that the real culprit is the code line > > OS.reserve(OS.size() + 64); > > called from

Could you dig into why: + raw_ostream &write(unsigned char C) override { + grow(1); + *OutBufCur++ = C; + return *this; + } Is 3 times as fast as raw_svector_ostream? I don't see a good reason why that should be any faster than: raw_ostream &operator<<(char C) { if (OutBufCur >= OutBufEnd) return write(C); *OutBufCur++ = C; return *this; }

Please commit. On Aug 20, 2008, at 8:02 PM, Zhongxing Xu wrote: > Index: include/llvm/ADT/APInt.h > =================================================================== > --- include/llvm/ADT/APInt.h (revision 55101) > +++ include/llvm/ADT/APInt.h (working copy) > @@ -20,6 +20,7 @@ > #include <cassert> > #include <iosfwd> > #include <string> >

On Aug 19, 2009, at 4:39 PM, Sean Callanan wrote: > thanks for your comments. I'll respond to them individually. I've > attached a new revision of the patch that addresses them. Patch > built and tested against SVN 79487, with the additional attached fix > that fixes an Intel table bug. Thanks Sean, comments below. Are you sure you attached the updated patch? I

+llvm-dev at lists.llvm.org The impact should be small as all the other streamers usually write directly to the memory buffer and only when out of buffer they call write(). OTOH, raw_svector_ostream (without a buffer) goes though write for every character or block it writes. It can work without virtual write() by overriding the existing virtual write_impl() but this is a slower code path for

Here's how I did things, back when I got to write my own infrastructure. It's still O(n^2) in the worst case, but *much* quicker in the expected case. Number all the basic blocks, 0 to n-1 and build a vector mapping from integer to block. Requires O(n) time and space. For each block, compute the set containing it's dominance frontier, based on Figure 10 of * * *Efficiently

Hi Russel, Can you try compiling aklo.o using -fno-rtti prior to linking? On Thu, Mar 24, 2016 at 11:44 PM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I'm trying to link a program with LLVM on Linux. I've managed to take out > the test files from 'llvm-config --libs' but now it's getting errors with > missing symbols. The same program

Since the log tells you that llvm::outs() is not found, and since it is supposed to be found in libLLVMSupport.a, you can try: $ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv ... 0000000000002070 T __ZN4llvm4outsEv ... The output should have the symbol defined. -- Mehdi > On Mar 25, 2016, at 12:18 AM, Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> wrote:

Looking again at your link line, I think static library has to appear after their uses. So try to put the .o before the list of library. -- Mehdi > On Mar 25, 2016, at 12:41 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > > Yeah, seems to. > > a at a-VirtualBox:~$ nm /home/a/build//lib/libLLVMSupport.a | grep ZN4llvm4outsEv > U