similar to: [LLVMdev] Fail to compile LLVM on Gentoo Linux

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

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

> >  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 Wed, Sep 12, 2012 at 08:52:08PM -0700, Jim Grosbach wrote: > > > 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

I installed R-2.3.1 and ran make check without problem, but I am having trouble installing several packages using gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-53) on Red Hat Enterprise Linux AS release 3 (Taroon Update 7) Kernel 2.4.21-40.ELsmp on an x86_64 Below are the messages from MCMCpack. Perhaps my systems are messed up? Paul Gilbert > install.packages("MCMCpack")

Hi, all I am trying to selfhost LLVM and Clang. Below is my flow, Step 1. Build LLVM and Clang by using native gcc $ ../llvm-2.9/configure --prefix=$INSTALL \ --enable-optimized Step 2. Build LLVM and Clang by using clang built by step 1 $ CC=clang CXX=clang++ ../llvm-2.9/configure \ --prefix=$INSTALL --enable-optimized But in step 2, I have a compilation error below, -- llvm[1]:

Hi all, I found this problem in the latest xen-unstable 6117. I reported a bug #154 to track it. The log====> <...> gcc -nostdinc -fno-builtin -fno-common -fno-strict-aliasing -iwithprefix include -Wall -Werror -Wno-pointer-arith -pipe - I/home/nightly/builds_xen_unstable/xen-3.0-hg-xen-unstable-6096- 20050812/xen/include -I/home/nightly/builds_xen_unstable/xen-3.0-hg-xen-

Per https://buildd.debian.org/build.php?pkg=r-base, we see the Alpha platform having trouble with deriv.c : gcc -I. -I../../src/include -I../../src/include -DHAVE_CONFIG_H -mieee-with-inexact -fpic -std=gnu99 -O3 -pipe -g -c deriv.c -o deriv.o deriv.c: In function 'simplify': deriv.c:267: error: unrecognizable insn: (insn 2103 64 65 9 ../../src/include/Rinlinedfuns.h:86 (set

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

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, 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 (陳韋任)

https://bugzilla.netfilter.org/show_bug.cgi?id=1685 Bug ID: 1685 Summary: Calling the nftnl_set_free function may trigger the "double free" problem. Product: libnftnl Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5

Hi, I am using xen 3.1.0 on opensuse 10.3, for more details see below. When I try to start the third domU, then this will not work, I get the error: Error: Boot loader didn''t return any data! When I shutdown an other one, I can successfully start the machine that failed, see my log below. The xen configuration files are all similar to this one: name="FTP"

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 >