similar to: [LLVMdev] Problem while selfhosting LLVM and Clang

This looks relevant to me for your issue. Grabbing the cxxabi.h from there may work: http://comments.gmane.org/gmane.comp.compilers.clang.devel/9391 -- Aaron Myles Landwehr On Sat, Jul 30, 2011 at 1:33 AM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi, all > > I am trying to selfhost LLVM and Clang. Below is my flow, > > Step 1. Build LLVM and Clang by using native gcc

Hi, Asron > This looks relevant to me for your issue. Grabbing the cxxabi.h from there > may work: > > http://comments.gmane.org/gmane.comp.compilers.clang.devel/9391 I am not sure where to put cxxabi.h. How can I let clang find this header file while compiling LLVM and Clang (in step 2)? Thanks! Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of

On Sat, Jul 30, 2011 at 2:35 AM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi, Asron > > > This looks relevant to me for your issue. Grabbing the cxxabi.h from > there > > may work: > > > > http://comments.gmane.org/gmane.comp.compilers.clang.devel/9391 > > I am not sure where to put cxxabi.h. How can I let clang find this > header file while

Hi, Aaron > > I am not sure where to put cxxabi.h. How can I let clang find this > > header file while compiling LLVM and Clang (in step 2)? > > > > You need to add it to somewhere that is in Clangs includes search path. E.g. > $INSTALL/lib/clang/2.9/include perhaps. Thanks for your help. Now I have another problem, --- llvm[4]: Compiling Version.cpp for Release

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

> /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

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 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

> >  But I got the error message below, > > > > --- > > 2012-04-12 02:39:48: executing test modules > > 2012-04-12 02:39:49: loading nightly test data... > > nt.py:737: fatal error: nightly test failed, no report generated > > --- > > > >  Any idea on how I can figure out what the fatal error is? Thanks! > > Inside the sandbox there will

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, Eli > Mmm... and I just realized I really can't help track this down because > the code paths in question are probably Linux-specific. I spent a I add the following line back to lib/Support/Unix/Host.inc, Arch = "arm"; And examples/HowToUseJIT works fine. Regards, chenwj [1] http://llvm.org/viewvc/llvm-project?view=rev&revision=131463 -- Wei-Ren Chen (陳韋任)

On Fri, Jul 8, 2011 at 9:30 AM, Karel Gardas <karel.gardas at centrum.cz> wrote: > On 07/ 8/11 05:26 PM, Eli Friedman wrote: >> >> Given that revision range, the only remotely likely culprit is 131463. >>  Which basically means that it "broke" because the default target >> features changed. > > And you are right here. 131463 == 131464 which is

On 07/ 8/11 05:26 PM, Eli Friedman wrote: > Given that revision range, the only remotely likely culprit is 131463. > Which basically means that it "broke" because the default target > features changed. And you are right here. 131463 == 131464 which is buggy. 131462 is OK. Thanks, Karel

Hi all, I am running LNT with LLVM/Clang 3.0 Release binary and test suite, here is my flow (most of them are the same as http://llvm.org/docs/lnt/quickstart.html). --- $ svn co http://llvm.org/svn/llvm-project/lnt/trunk ~/lnt $ ~/mysandbox/bin/python ~/lnt/setup.py develop $ cd mysandbox; source bin/activate $ $ lnt runtest nt \ --sandbox SANDBOX \ --cc

On Wed, Apr 11, 2012 at 7:59 PM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi all, > >  I am running LNT with LLVM/Clang 3.0 Release binary and test suite, here is my > flow (most of them are the same as http://llvm.org/docs/lnt/quickstart.html). > > --- > $ svn co http://llvm.org/svn/llvm-project/lnt/trunk ~/lnt > $ ~/mysandbox/bin/python ~/lnt/setup.py develop >

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 It seems that rev. 131463 [1] makes LLVM failed to recognize ARM correctly. My best guess is the variable LLVM_HOSTTRIPLE got something like "armv7l-unknown-linux-gnueabi" when LLVM compiled natively on ARM. Then the Arch (armv7l) is not recognized by LLVM. As you can see from attach (llvm-131463-gcc-4.4.1-native-arm2.log), there are a lot failure while running test cases

Hi, all I am trying to selfhost LLVM and Clanf on ARM. Hopefully doing this can reveal what version of GCC is broken. But I have a concern about the following message while building LLVM and Clang by using clang (selfhost build). --- llvm[1]: Compiling DeltaAlgorithm.cpp for Debug build /tmp/cc-DqWGS1.s: Assembler messages: /tmp/cc-DqWGS1.s:8963: Rd and Rm should be different in mul llvm[1]:

Attempting to build llvm on Mageia2 from the 3.3 source I get: "#include "..." search starts here: #include <...> search starts here: /home/mgeldiener/dev/clang/build/include /home/mgeldiener/dev/clang/build/lib/Support /home/mgeldiener/vcs/llvm/include /home/mgeldiener/vcs/llvm/lib/Support /opt/intel/composerxe-2011.5.220/mkl/include

On Mageia 2 I have installed the binary clang package clang3.0-7. When I tried to build the latest llvm/clang from source using this binary clang I get this error: 1) In file included from /home/mgeldiener/vcs/llvm/lib/Support/Signals.cpp:30: /home/mgeldiener/vcs/llvm/lib/Support/Unix/Signals.inc:32:10: fatal error: 'cxxabi.h' file not found #include <cxxabi.h> ^ llvm[1]: