similar to: [LLVMdev] sys::getHostTriple failed to recognize ARM correctly

On Fri, Nov 4, 2011 at 3:11 PM, <spop at codeaurora.org> wrote: > Hi Daniel, > >> Sebastian, this looks like it is most likely some kind of fallout from >> your changes. > > Thanks for letting me know about these failing testcases. > > In the logs of the buildbot: >

I actually tend to agree with spop, it's cleaner to compute things at runtime than at compile time. One particular reason is wanting to pick the best target CPU for the current arch (which may not be what was compiled for). The current JIT target selection logic is really gross, I do believe that it tried to do this, but it probably needs some spring cleaning. Sebastian, can you try and take

Hi Daniel, > Sebastian, this looks like it is most likely some kind of fallout from > your changes. Thanks for letting me know about these failing testcases. In the logs of the buildbot: http://lab.llvm.org:8011/builders/llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi/builds/273/steps/run.build.step.configure_llvm_1/logs/stdio I see that the bot is configuring llvm with:

Hello. I've built and `make chech-all` rc3 tarballs using CMake build on FreeBSD 8-STABLE system. Here are results: Failing Tests (10): Clang :: Index/crash-recovery-code-complete.c Clang :: Index/crash-recovery-reparse.c Clang :: Index/crash-recovery.c LLVM :: BugPoint/crash-narrowfunctiontest.ll LLVM :: BugPoint/metadata.ll LLVM :: BugPoint/remove_arguments_test.ll

Hi, I noticed that the following regression tests fail when building a config generated with CMake. When building with a config generated with configure, all is well. I get the same results when using gcc-4.2.1 and clang-trunk. It seems to me that there's a glitch in de CMake config somewhere. I doing a verbose build right now to investigate, but maybe someone already knows what's

Hi, I have successfully built a shared version of LLVM (both 3.0rc4 and 2.9) on Windows 7 using MinGW. From there, I thought I would run the tests located under unittests (i.e. ADTTests, AnalysisTests, ExecutionEnginetests, JITTests, SupportTests, UtilsTests and VMCoreTests). All of them pass without any problem, except for JITTests which fails on the MultiJitTest.JitPool test:

2011/11/18 Alan Garny <alan.garny at dpag.ox.ac.uk>: > I have successfully built a shared version of LLVM (both 3.0rc4 and 2.9) on > Windows 7 using MinGW. From there, I thought I would run the tests located > under unittests (i.e. ADTTests, AnalysisTests, ExecutionEnginetests, > JITTests, SupportTests, UtilsTests and VMCoreTests). All of them pass > without any problem,

Is MC JIT support expected in 3.0, and if not, what does the timeline look like? Would I be better off trying to get the supported but incomplete MC JITter working than spending effort preserving the dead branch? Thanks Craig On Aug 30, 2011, at 4:44 PM, James Molloy wrote: > Hi Craig, > > > The problem with this is that the ARM JIT was never gotten to "supported"

Hi Craig, The problem with this is that the ARM JIT was never gotten to "supported" status at any point, so regressions were not monitored. The code path is essentially dead, at the moment, with noone willing to invest time in flogging a dead horse as it'll all have to be rewritten when MC lands properly and someone has the time/inclination to architect it. I understand your

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

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

On Aug 30, 2011, at 3:12 PM, Owen Anderson wrote: > The non-MC-based ARM JIT path is known not to work, and nobody is working on fixing it. The MC-based instruction encoder is rapidly maturing is generally passable for static encoding, but the MCJIT is still in its infancy. I was relying on this support in LLVM 2.8, and while it is definitely incomplete, it does work if you don't depend

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

Craig, On Aug 30, 2011, at 12:51 PM, Craig Smith wrote: > I recently tried to update from LLVM 2.8 and 2.9 and ran into several bad issues with JIT support on ARM. > I ran into several distinct issues so far, and there are probably others. (None of these problems appear to be fixed in the current svn head either as far as I can tell.) The non-MC-based ARM JIT path is known not to work,

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

Hi all, I was wondering if anyone could help me out with my MCJIT bug on LLVM 3.2. The same code works beautifully on x86 desktop with the same version of LLVM. This is the error I've been getting on ARM platforms: dsheffie at tegra-ubuntu:~/projects/threeFingeredJack/python_compile$ python ./vvadd.py [ 0. 0. 0. ..., 0. 0. 0.] ARMCodeEmitter::emitPseudoInstruction UNREACHABLE

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