similar to: [LLVMdev] Where do I update release notes for the 3.7 release?

Dear everyone, The in-progress release notes for 3.7 [1,2] make it look like we didn't do very much over the past six months. Obviously that's not the case at all, so let's get them in shape! If you've been thinking "I should probably add this to the release notes at some point", now is the time :-) I have a list below of changes that might be worth mentioning. I

It seems this is a cmake vs autoconf thing. With cmake, it builds correctly, but with autoconf I get the same error as you. I probably shouldn't have made this change while we were in the release process as it was potentially risky :-/ I've reverted it now, so hopefully the next build should be problem free. Thanks, Hans On Fri, Aug 21, 2015 at 5:09 AM, Dimitry Andric <dimitry at

Hi Dmitry, if I understood Hans clang-extra wasn't part of the build prior to rc3. Just delete it and run script with --no-checkout. On Fri, Aug 21, 2015 at 7:15 PM, Dimitry Andric <dimitry at andric.com> wrote: > Hm, it does not seem to compile at all here? The build ends with: > > In file included from >

The problem seems to be caused by the way the symlinks are setup in test-release.sh, e.g. like so: llvm.src/tools/clang -> ../../cfe.src cfe.src/tools/extra -> ../../clang-tools-extra.src When it then tries to access the path llvm.src/tools/clang/tools/extra/clang-apply-replacements/lib/Tooling/../../../../../include, it fails. I tried this on both FreeBSD, OSX and Linux, but it fails

Still no complete go, doing the tests on i386 failed with some weird sed error: [...] Making Unit/lit.site.cfg for Clang extra tools... sed: lit.tmp: No such file or directory Makefile:61: recipe for target 'Unit/lit.site.cfg' failed gmake[2]: *** [Unit/lit.site.cfg] Error 1 Strangely enough, this does not happen on amd64. Maybe it is some sort of race condition? Did anybody see this

Hello everyone, Source, binaries and docs for LLVM 3.7.0-rc2 are now available at http://llvm.org/pre-releases/3.7.0/ Please try them out, run tests, build your favourite projects, and *file bugs* reporting any issues that you find. We are now getting into the part of the release process where it's time to wrap things up, so if you were thinking about doing some tests or getting something

Hi all, I am working on adding PGO to LDC (LLVM D Compiler). The current implementation 1) uses LLVM's InstrProf pass to generate an instrumented executable 2) links to compiler-rt/lib/profile for the runtime functionality to write a raw profile data file 3) uses llvm-profdata to merge profile data and convert from profraw to profdata format 4) uses llvm::IndexedInstrProfReader to read-in

On 19 Jul 2015, at 17:32, Dimitry Andric <dimitry at andric.com> wrote: > > On 19 Jul 2015, at 01:44, Dimitry Andric <dimitry at andric.com> wrote: > ... >> Hm, strangely enough, this version of the script does not go further than the Phase 2 installation, and does not run any tests? This used to work fine for the release_36 branch. >> >> I think it is

On Wed, 15 Apr 2020 at 17:28, David Blaikie <dblaikie at gmail.com> wrote: > > opaque pointers don't exist in the IR yet - the goal is to reduce the places that use non-opacity of pointer types already/today and then opacify the existing pointer type, rather than introducing an opaque pointer type & having it concurrently with non-opaque pointer types. (though in retrospect

On 19 Jul 2015, at 00:17, Dimitry Andric <dimitry at andric.com> wrote: > > On 17 Jul 2015, at 01:09, Hans Wennborg <hans at chromium.org> wrote: >> >> On Thu, Jul 16, 2015 at 3:47 PM, Dimitry Andric <dimitry at andric.com> wrote: >>> On 17 Jul 2015, at 00:31, Hans Wennborg <hans at chromium.org> wrote: >>>> >>>> Dear

On Tue, 14 Apr 2020 at 21:24, Michael Kruse <llvmdev at meinersbur.de> wrote: > > Currently, LLVM often uses the *i8 type (pointer to char) to represent > a pointer to some not-specified type. We are also working on replacing > the pointer-to-type pointer types by a single pointer type without a > specific pointee-type. Look for "opaque pointer" on llvm-dev and the

I.e., I see this when I run `git fetch`: ``` $ git fetch -v llvm.org From http://llvm.org/git/llvm = [up to date] master -> llvm.org/master = [up to date] release_1 -> llvm.org/release_1 = [up to date] release_16 -> llvm.org/release_16 = [up to date] release_20 -> llvm.org/release_20 = [up to date] release_21 -> llvm.org/release_21 = [up to date]

From: Hervé Poussineau <hpoussin@reactos.org> Signed-off-by: Hervé Poussineau <hpoussin@reactos.org> Signed-off-by: Andreas Färber <afaerber@suse.de> --- hw/xen_platform.c | 21 ++++++++++----------- 1 Datei geändert, 10 Zeilen hinzugefügt(+), 11 Zeilen entfernt(-) diff --git a/hw/xen_platform.c b/hw/xen_platform.c index ca66047..8866468 100644 --- a/hw/xen_platform.c +++

> On 2016-Feb-05, at 15:22, James Y Knight <jyknight at google.com> wrote: > > That usually happens when someone deletes and then recreates an svn branch with the same name, as happened in r215001 and r215011. > It can be deleted now, if anyone wants to. ``` $ git push llvm.org :release_35 at 215010 fatal: unable to access 'http://llvm.org/git/llvm.git/': The requested

On Wed, Feb 18, 2015 at 6:58 AM, Colin LeMahieu <colinl at codeaurora.org> wrote: > It might help after adding explicit types where needed and before adding > the opaque pointer type, to change all pointers to a single type in the > existing type system, i8* could work or maybe a weird type that would shake > out any issues like i99*. > I'm not sure this would help

Hello all, I'm writing a backend for our scriptlanguage compiler and I'm currently writing an IR module for the runtime library that contains some support routines called by generated code. The IR module contains calls to "malloc", which depend on the size of "size_t". Since I don't know the target when writing the IR module for the runtime library, I

Hello, I am writing a compiler which outputs LLVM for my own custom language. Thanks to everybody who has contributed to the project it really is an impressive tool chain. I downloaded the 3.7 release from the website and I noticed that there had been a change to getelementptr. I can see the new syntax in the latest version of the Language Reference Manual but I could find no other reference to

On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev < lldb-dev at lists.llvm.org> wrote: > ----- Original Message ----- > > From: "Hans Wennborg via cfe-dev" <cfe-dev at lists.llvm.org> > > To: "llvm-dev" <llvm-dev at lists.llvm.org>, "cfe-dev" < > cfe-dev at lists.llvm.org>, "LLDB Dev" <lldb-dev at

On Tue, Feb 17, 2015 at 10:47 PM, David Blaikie <dblaikie at gmail.com> wrote: > > > On Tue, Feb 17, 2015 at 10:27 PM, Chris Lattner <clattner at apple.com> > wrote: > >> On Feb 17, 2015, at 1:58 PM, Chandler Carruth <chandlerc at gmail.com> >> wrote: >> > I'm not actually worried about this change though Chris, at least >> w.r.t.

Dear everyone, We're getting close to the 6.0.0 release, but the release notes are still in a pretty bad state. You can see the notes for rc2 here: http://prereleases.llvm.org/6.0.0/#rc2 (a few things have been added since). When the release happens, a lot of people will look at the notes, so it's a good opportunity to mention the work that's happened in the past six months. If you