similar to: [LLVMdev] reproducing binaries on llvm.org

> The script used for building the binaries can be found under llvm : > utils/release/test-release.sh Thanks! A few follow-up questions: > # Phase 3: Build llvmCore with newly built clang from phase 2. > c_compiler="$gcc_compiler -fplugin=$dragonegg_phase2_objdir/dragonegg.so" > cxx_compiler="$gxx_compiler

On Tuesday 09 July 2013 15:11:03 Greg Fitzgerald wrote: > Are the packaging scripts used to produce the clang+llvm binaries on > llvm.org under version control? If so, can you please point me to > them? The script used for building the binaries can be found under llvm : utils/release/test-release.sh The packages are mere tarballs of the installation dir. Cheers, > > Thanks,

Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> writes: > The first layout is older, and the second is newer. Going forward, > things are likely to move around. The second layout is more flexible > because it doesn't put any repo inside another repo, so I would > recommend adopting it. At the very least, using it will put you in a > good position to adapt to any

I was a bit confused with what the difference was between the old target_link_libraries(foo bar) and the new target_link_libraries(foo INTERFACE|PRIVATE|PUBLIC bar) To try to find out, I decided to look at the generated build.ninja. The difference that shows up is far fewer order only dependencies. For example build lib/TableGen/CMakeFiles/LLVMTableGen.dir/Error.cpp.o: CXX_COMPILER

Sorry for the delay in writing this up and sending it out, but I wanted to recap the discussion from the roundtable on October 23rd. The roundtable ran for almost two hours and we discussed at most of the main points in my RFC. Thank you everyone who participated and contributed to the discussion! TL;DR: We should move to CMake 3.15 (RFC incoming). We should make `all` really `all`. We should

Speaking on how to locate/enable projects (like clang/lldb) - even with the monorepo, I'm still enabling clang/lldb by symlinking them into llvm/tools, for one specific reason: CMake and relative paths. As long as all the source that is being built is below the toplevel CMake directory, and the build directory itself is within the toplevel CMake project directory, CMake uses relative

Without this option, configure will fail when there is no display. Signed-off-by: Masami HIRATA <msmhrt at gmail.com> --- configure.ac | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index de8a064..61d6f69 100644 --- a/configure.ac +++ b/configure.ac @@ -593,16 +593,16 @@ working. AC_MSG_FAILURE([$QEMU version must be >=

Another test, the same as before.

Best of .. 4?

After enabling procmail debugging ...

This is a repost so I can test my procmail script / automatic testing framework. The patch series is identical to v1. Rich.

Patch 1 cleans up the gobject tests. Patches 2 and 3 remote gtk-doc, which is slow and useless, and replace it with a simple manual page. https://bugzilla.redhat.com/show_bug.cgi?id=1465665 Rich.

George Karpenkov <ekarpenkov at apple.com> writes: > Should -DCMAKE_CXX_COMPILER be also specified? CMake is smart enough to infer that from C_COMPILER: % grep CMAKE_CXX_COMPILER CMakeCache.txt CMAKE_CXX_COMPILER:FILEPATH=/Users/bogner/llvm-lkgc/bin/clang++ >> On Aug 24, 2017, at 11:29 AM, Justin Bogner <mail at justinbogner.com> wrote: >> >> (kcc, george:

Ah, that makes a lot of sense. Thank you! Do you have any tips (or points to documentation) for how to run compiler-rt tests? Just invoking llvm-lit doesn't seem to work On 01/03/2018 11:17 PM, Sean Silva wrote: > Typically this would be tested alongside the runtime component in > compiler-rt. > For example, PGO instrumentation has its "end-to-end" tests in >

Typically this would be tested alongside the runtime component in compiler-rt. For example, PGO instrumentation has its "end-to-end" tests in https://github.com/llvm-mirror/compiler-rt/tree/master/test/profile -- Sean Silva On Tue, Jan 2, 2018 at 11:16 AM, Eli Davis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello! > > I am writing an instrumentation pass using

On Wed, Mar 8, 2017 at 3:23 PM Chris Bieneman <beanz at apple.com> wrote: > On Mar 8, 2017, at 3:16 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > > On Wed, Mar 8, 2017 at 2:55 PM Chris Bieneman <beanz at apple.com> wrote: > > David, > > This is an area that has had a lot of development over the last two years. > > There are two supported

Hello All, Another newbie question. I am confused as to what options will work with "fplugin-arg-dragonegg-llvm-option" for dragonegg plugin. Readme says it is used to pass command-line options to llvm. I shall consolidate into 3 questions. For all examples below, I used combo- gcc 4.6 + dragonegg(trunk) + llvm(trunk) (1). Does 'fplugin-arg-dragonegg-llvm-option' allow all

klibc currently builds and installs differently depending on the locale and umask at build time. This series fixes that. Ben. Ben Hutchings (2): Install headers with consistent mode dash: mkbuiltins: Fix sort order harder scripts/Kbuild.install | 2 +- usr/dash/mkbuiltins | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text

On Tue, 3 Apr 2012 08:57:51 -0400 Jack Howarth <howarth at bromo.med.uc.edu> wrote: > On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote: > > Hi Jack, > > > >> Attached are the Polyhedron 2005 benchmark results for current > >> llvm/dragonegg svn on x86_64-apple-darwin11 built against Xcode > >> 4.3.2 and FSF gcc 4.6.3. > > >

On Tue, Apr 03, 2012 at 09:26:38AM +0200, Duncan Sands wrote: > Hi Jack, > >> Attached are the Polyhedron 2005 benchmark results for current llvm/dragonegg svn >> on x86_64-apple-darwin11 built against Xcode 4.3.2 and FSF gcc 4.6.3. > > thanks for the numbers. How does this compare to LLVM 3.0 - were there any > regressions? The results from just before