similar to: [LLVMdev] Broken build 'clang-x86_64-darwin10-self-mingw32'

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

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

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:

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

The host c++ standard library is missing <utility>, it appears. On Sep 20, 2011, at 11:22 AM, Galina Kistanova wrote: > Please use the correct link : > http://63.145.236.72:8011 > and ignore the previous. > > Also log for broken build is here: > > make[1]: Entering directory >

Hello everybody, Just a short note that clang build "clang-native-arm-cortex-a9" is broken and the very last successful build was for revision 139932. All newer revisions fail. The builder is available here: http://172.16.0.135:8011/waterfall Thanks Galina

Please use the correct link : http://63.145.236.72:8011 and ignore the previous. Also log for broken build is here: make[1]: Entering directory `/home/buildslave/zorg/buildbot/osuosl/slave/clang-native-arm-cortex-a9/llvm/lib/Support' llvm[1]: Compiling APFloat.cpp for Release+Asserts build llvm[1]: Compiling APInt.cpp for Release+Asserts build In file included from APFloat.cpp:15: In file

I’ve had another look, and some of the failing tests don’t use temporary files, so I don’t think this is a case of tests having side-effects. Instead, I’ve noticed that in the build log (http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/6552/steps/build-unified-tree/logs/stdio), llvm-tblgen.exe is built (my patch modified it), but the table-generation steps of the

Yeah. That code has been there since r91421 and wouldn't have failed recently otherwise. Did something change on the host? -eric On Sep 20, 2011, at 11:27 AM, Jim Grosbach wrote: > The host c++ standard library is missing <utility>, it appears. > > > On Sep 20, 2011, at 11:22 AM, Galina Kistanova wrote: > >> Please use the correct link : >>

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

Hi all, There's been a recent bootstrap failure that might be covered up because of another failure. I just wanted to point this out so that people can take a look: -bw Here's the failure from our buildbot: Assertion failed: (DestReg == VirtReg && "Unknown load situation!"), function RewriteMBB, file /Volumes/Sandbox/Buildbot/llvm/build.llvm-

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

I hope this is the place for this... I have to rebuild from scratch under Snow Leopard, and when I attempted to build R-2.9.1, I get the following results from ./ configure: checking how to get verbose linking output from fc... configure: WARNING: compilation failed checking for Fortran 77 libraries of fc... checking how to get verbose linking output from gcc -std=gnu99... -v checking for

Can anyone shed some light on the origins of the comments... /* Mach-O doesn't support omitting the frame pointer for now. */ ...in gcc/config/i386/i386.c. FSF gcc trunk has enabled the omit-frame-pointer option as the default for both i386 and x86_64 recently. * config.gcc: Handle --enable-frame-pointer. * configure.ac: Add --enable-frame-pointer. * configure: Regenerated. *

On Tue, 12 Jun 2012 11:15:12 +0200 Tobias Grosser <tobias at grosser.es> wrote: > On 02/05/2012 02:42 PM, Hal Finkel wrote: > > I think that it would be a good idea to have a buildbot set up to > > run the test suite with -vectorize. Could one of the existing > > machines do this also? > > It took some time, but we have this now: > >

Hm, I also note that: $ file /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as /opt/clang+llvm-2.7-i386-darwin10/bin/llvm-as: Mach-O 64-bit executable x86_64 Why's the i386 package have an x86_64 binary in it? That could explain why it doesn't work on darwin9. On Fri, Mar 19, 2010 at 9:49 AM, Jeffrey Yasskin <jyasskin at google.com> wrote: > Hi Tanya, > > On darwin9, the

The current dragonegg trunk svn used under FSF gcc 4.5.2 with llvm 2.9 is able to bootstrap FSF gcc 4.5.2 itself on x86_64-apple-darwin10... Using built-in specs. COLLECT_GCC=gcc-mp-4.5 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.5.2/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../gcc-4.5.2/configure --prefix=/opt/local --build=x86_64-apple-darwin10