similar to: [LLVMdev] Dragonegg buildbots

[This email is either empty or too large to be displayed at this time]

Hi All, Recent conversations [1][2] would suggest we need to rethink zorg or at the very least improve the documentation. I've CC'ed Daniel Dunbar, Galina Kistanova and Duncan Sands because it seemed that they have contributed the most code to Zorg Organisation ========= The current organisation of the Zorg repository doesn't make a huge amount of sense from my perspective. There

Hi all, I just don't have time to look after dragonegg properly any more, so I'm looking for someone to care over the care and feeding of this project. This not only means ensuring that it continues to compile and work, it also means - making sure dragonegg makes use of new LLVM features (eg struct TBAA) - making sure it works with new versions of GCC, and supports interesting new GCC

Hi folks, *tl;dr* I'm having some trouble setting up a Windows buildbot and I'm looking for someone with LLVM-on-Windows experience to help me. *Long story* Hans Wennborg recently pointed <http://lists.llvm.org/pipermail/llvm-dev/2020-May/141803.html>out <http://lists.llvm.org/pipermail/llvm-dev/2020-May/141803.html>, that we're missing a 32 bit Windows buildbot and I

It has just been brought to my attention that our buildbots no longer report failures to compile/link files in the test-suite as failures for the build. As a result, we have at least one bot that is currently showing a green status, yet it aborts when building 3 test cases. I assume that something has changed with how (presumably LNT) reports these failures and the Zorg code does not adequately

I've been trying to package DragonEgg for Fedora Linux. Fedora 16 has LLVM 2.9 and GCC 4.6, but not the necessary GCC patches. If I build LLVM 3.0 on Fedora 16, then I can build DragonEgg 3.0, and it works fine. However, I can't submit that to the repository. On the other hand, Fedora 17, which just entered Beta, has LLVM 3.0 and GCC 4.7. I wasn't able to build DragonEgg 3.0

hi Duncan, >> >>> That said, it still doesn't compile because you seem >>> to have LLVM from svn installed not llvm-2.9, and dragonegg-2.9 needs to >>> be >> >> yep, the dragonegg is also from svn when i try: /home/ether/local/gcc-4.5/bin/gcc -S -O1 -o - -fplugin=$HOME/sources/dragonegg/dragonegg.so -fplugin-arg-dragonegg-emit-ir

How about tweaking the compiler-rt cmakefiles so that if lsan is not supported, the target check-lsan still exists but does nothing? I've attached a patch that does this. (I don't know much about cmake so there might be a better way of doing it.) Alternatively, can I change the zorg build script so that "run sanitizer tests in gcc build" doesn't try to run check-lsan etc

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

There as been a bit of talk about zorg recently, so I thought this would be a good time to share our plans for the darwin buildbots that live here: http://lab.llvm.org:8013/builders <http://lab.llvm.org:8013/builders> To be clear, those are not these buildbots: http://lab.llvm.org:8011/builders <http://lab.llvm.org:8011/builders> We are not talking about changing the main

On Apr 19, 2011, at 6:59 AM, Jack Howarth wrote: > 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 >

Hi, Currently the first stage ("run sanitizer tests in gcc build") of the sanitizer-ppc64-linux1 buildbot is only failing because of: + cd clang_build + make -j16 check-lsan make: *** No rule to make target `check-lsan'. Stop. + echo @@@STEP_FAILURE@@@ @@@STEP_FAILURE@@@ + cd clang_build + make -j16 check-msan make: *** No rule to make target `check-msan'. Stop. + echo

hi, On Fri, Apr 8, 2011 at 8:38 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: >   The new dragonegg 2.9 sources fail to build against either FSF gcc 4.5.2 or 4.5.3svn > (with the i386_static.diff patch applied) on x86_64-apple-darwin10. In both cases, the > build fails as... Dragonegg revision 129116 also fail on x86_64 linux, with gcc-4.5 revision 172158, i got:

Hi all, I tried using dragonegg to compile some numerical software of ours. I tried out two different approaches expecting both would yield the same results: 1. gfortran-4.6 -fplugin=dragonegg-3.0 -o test.o test.f (I ommitted a bunch of additional arguments for brevity) 2. gfortran-4.6 -fplugin=dragonegg-3.0 -fplugin-arg-dragonegg-emit-ir -S -o test.ll test.f llc -O0 -o test.s test.ll as

Hello All, I am in need of dragonegg support for the latest version of llvm. I tried to make dragonegg with the latest versions but it fails. It is able to be maked with the llvm version 3.3 only with GCC 4.6. I am trying this on my ubuntu system. I tried to make dragonegg with various combinations of llvm and GCC versions but the only combination which seems to be working is LLVM-3.3, GCC-4.6

Hi, I'm not sure if this is a configuration controlled centrally, but if it is, is there any way to disable or extend the process timeout on the lab.llvm.org buildbots? It doesn't seem to serve much purpose except to introduce false build failures, such as these from clang-x86_64-ubuntu: http://lab.llvm.org:8011/builders/clang-x86_64-ubuntu/builds/9519

My thought was that its reasonable to expect no warnings when building from bootstrap (as you say) and the last release of Clang. Generally, I think we should work around warnings in the last release of Clang if only for the convenience of folks using that release to build stage1 and using Werror. Certainly, we tend to fix warnings even from earlier Clang versions and from GCC in order to keep

Hi ether, > i install mpc-0.8.2 in /home/ether/local/, and gcc-4.5 is configure with: > $HOME/sources/gcc-4.5/configure --enable-plugin --enable-lto > --prefix=$HOME/local/gcc-4.5/ --enable-languages=c,c++ > --disable-bootstrap --disable-multilib --with-mpc=$HOME/local > --with-libelf=$HOME/local because GCC headers include mpc.h, when dragonegg uses GCC headers then it needs to

Hello everyone, The buildbot upgrade is entering the phase when the results to become visible. No change is required at this time on any of the builders. The bot owners could upgrade the buildbot on build computers later, at their convenience, as this is not on the critical path. We are going to upgrade the staging bot first. Then, once that is stable and all detected issues are resolved, we

Hello everyone, It might make sense to start from rebooting the buildmaster, just to make sure everything is all right on this end. Yesterday I have tried to apply the latest changes from zorg and some of them are broken. Theoretically, checkconfig shouldn't affect the working instance, but the reality could be different... I planned to rollback to the last known-to-be-good revision and