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

Displaying 20 results from an estimated 5000 matches similar to: "[LLVMdev] Broken build 'clang-x86_64-darwin10-self-mingw32'"

2011 Oct 08
1
[LLVMdev] [cfe-commits] 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: > >
2011 Oct 08
0
[LLVMdev] [cfe-commits] Broken build 'clang-x86_64-darwin10-self-mingw32'
>> >> 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
2011 Oct 08
1
[LLVMdev] [cfe-commits] Broken build 'clang-x86_64-darwin10-self-mingw32'
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.
2011 Nov 04
0
[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: >
2011 Nov 04
7
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
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:
2011 Nov 04
1
[LLVMdev] JIT should query host info at runtime - Re: buildbot failure in LLVM on llvm-gcc-build-x86_64-darwin10-x-mingw32-x-armeabi
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
2011 Sep 20
2
[LLVMdev] Clang build "clang-native-arm-cortex-a9" is broken
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 >
2011 Sep 20
3
[LLVMdev] Clang build "clang-native-arm-cortex-a9" is broken
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
2011 Sep 20
0
[LLVMdev] Clang build "clang-native-arm-cortex-a9" is broken
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
2017 Dec 06
3
buildbot failure in LLVM on llvm-clang-x86_64-expensive-checks-win
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
2011 Sep 20
1
[LLVMdev] [cfe-commits] Clang build "clang-native-arm-cortex-a9" is broken
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 : >>
2011 Nov 04
0
[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 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:
2011 Nov 04
1
[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 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
2009 Nov 12
2
[LLVMdev] Bootstrap Failure
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-
2009 Sep 21
2
[LLVMdev] OT: gdb and procmod on darwin9.8/darwin10
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
2009 Sep 22
1
Snow leopard ./configure "cannot compile a simple Fortran program"
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
2010 Aug 16
3
[LLVMdev] -fomit-frame-pointer on intel darwin
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. *
2012 Jun 20
2
[LLVMdev] buildbot with -vectorize
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: > >
2010 Mar 19
1
[LLVMdev] 2.7 Pre-release1 available for testing
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
2011 Apr 19
2
[LLVMdev] dragonegg bootstrap gcc 4.5.2
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