similar to: [LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi

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

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

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,

On Sun, Jul 3, 2011 at 11:32 PM, Karel Gardas <karel.gardas at centrum.cz> wrote: > Hello, > > I asked here for kind of reference GCC version which LLVM development > team is using for *native* testing on ARM hardware. (no cross > compilation!) last week or so. I've been curious myself how the > situation looks and so I tested LLVM 2.9 as a reference point and LLVM >

On Nov 4, 2011, at 3:11 PM, spop at codeaurora.org wrote: > I think that for JIT, the compiler should figure out what the host > is with a *runtime* check (i.e., the JIT should not use the info from > the configure flag --host.) That seems reasonable. Would you update this please? Thanks! -eric -------------- next part -------------- An HTML attachment was scrubbed... URL:

> > On Nov 4, 2011, at 3:11 PM, spop at codeaurora.org wrote: > >> I think that for JIT, the compiler should figure out what the host >> is with a *runtime* check (i.e., the JIT should not use the info from >> the configure flag --host.) > > That seems reasonable. Would you update this please? > Yes, I would be happy to find the best fix for this. Thinking a

Hello, I asked here for kind of reference GCC version which LLVM development team is using for *native* testing on ARM hardware. (no cross compilation!) last week or so. I've been curious myself how the situation looks and so I tested LLVM 2.9 as a reference point and LLVM HEAD as of June 29 on ARMv7 (two boards with two different Ubuntu versions) compiled by GCC 4.3.4, 4.4.1, 4.4.5,

Hello everybody, Just a short note that clang build "clang-x86_64-darwin10-self-mingw32" is broken and the very last successful was build #465 for revision 141282. All newer revisions fail. The builder is available here: http://63.145.236.72:8011/builders/clang-x86_64-darwin10-self-mingw32/builds/505 Thanks Galina

Erik de Castro Lopo <mle+cl <at> mega-nerd.com> writes: > > Hi all, > > I'm compiling current SVN HEAD on Linux/x86. The tests are failing > on PowerPC due to the following assertion failure : > > JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: > getMachineOpValue(const llvm::MachineInstr&, const

On Fri, Oct 7, 2011 at 3:21 PM, Galina Kistanova <gkistanova at gmail.com>wrote: > Hello everybody, > > Just a short note that clang build "clang-x86_64-darwin10-self-mingw32" is > broken and the very last successful was build #465 for revision 141282. > All newer revisions fail. > > The builder is available here: > >

Hi all, I'm compiling current SVN HEAD on Linux/x86. The tests are failing on PowerPC due to the following assertion failure : JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: getMachineOpValue(const llvm::MachineInstr&, const llvm::MachineOperand&) const: Assertion `MovePCtoLROffset && "MovePCtoLR not seen yet?"'

>> >> http://63.145.236.72:8011/builders/clang-x86_64-darwin10-self-mingw32/builds/505 > > This looks like Peter's work on clang-tblgen vs. llvm-tblgen.... Yes, exactly. It seems cross-builds were not updated to this new scheme -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Sat, Oct 08, 2011 at 12:32:54PM +0400, Anton Korobeynikov wrote: > >> > >> http://63.145.236.72:8011/builders/clang-x86_64-darwin10-self-mingw32/builds/505 > > > > This looks like Peter's work on clang-tblgen vs. llvm-tblgen.... > Yes, exactly. It seems cross-builds were not updated to this new scheme This is now fixed as of Clang r141453/LLVM r141454.

On Mar 20, 2013, at 12:14 PM, Stephen Checkoway <s at pahtak.org> wrote: > I assume the CMAKE_SHARED_LIBRARY_LINK_C_FLAGS and CMAKE_SHARED_LIBRARY_LINK_CXX_FLAGS could be set empty initially and then for those that need it, set it (or something else) to -rdynamic. Attached is a small patch that sets CMAKE_SHARED_LIBRARY_LINK_CXXFLAGS to "" (as per your patch which I

The gdb developers are rapidly approaching the release of gdb 7.0 (which will be required to debug optimized code generated by gcc 4.5 due changes related to the var tracking association merge and other code). They currently have patches proposed that allows gdb 7.0 to debug code in darwin9.6. However there was some change made in darwin9.8 and darwin10 which no longer allows the previous

https://bugzilla.samba.org/show_bug.cgi?id=7667 Summary: "devices" regression test fails on x86_64-apple-darwin10 Product: rsync Version: 3.1.0 Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P3 Component: core AssignedTo: wayned at samba.org