similar to: [3.7 Release] Release Candidate 2 available

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

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]

> 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

Hi Hans, I'm wondering where I should commit 3.7 release notes - I really should add a note about the opaque pointer stuff so people have a bit of an idea of what's going on... - Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150730/8747b439/attachment.html>

On Wed, Dec 03, 2014 at 11:51:07AM -0800, Michael Zolotukhin wrote: > Hi Tom, > > I also have several patches that might be useful in 3.5.1. They all are stability fixes: > > r221009: Correctly update dom-tree after loop vectorizer. > r222451: Fix a trip-count overflow issue in LoopUnroll. > r223170 and r223171: PR21302.Vectorize only bottom-tested loops. > Hi Arnold,

I use the one from mingw.org, installed by the recommended way with mingw-get-setup.exe. Sly. On 30.08.2015 06:10, Yaron Keren wrote: > Which mingw distribution exactly do you use? > > 2015-08-30 0:46 GMT+03:00 Slycelote via llvm-dev <llvm-dev at lists.llvm.org>: > >> Hi all, >> >> I'm hitting the same problem as in this[1] thread. I use release_37

Hi James, Thanks for the help. From the log, I could infer that SLP vectorizer is not preserving alias analysis, preventing GVN from getting the info. Although the first function to get compiled has GlobalsAA available during GVN, rest of them do not as SLP vectorizer run on that function invalidates GlobalsAA which is a module pass. Is there a way to force re-computation of a particular

Hi all, I'm hitting the same problem as in this[1] thread. I use release_37 branch on 64-bit Windows 7. The problem is here: #ifdef __MINGW32__ #include <imagehlp.h> #else #include <dbghelp.h> #endif <skip> typedef BOOL (WINAPI *fpEnumerateLoadedModules)(HANDLE,PENUMLOADED_MODULES_CALLBACK64,PVOID); imagehlp.h doesn't define PENUMLOADED_MODULES_CALLBACK64 type. I

Followed the instructions here: http://www.freebsd.org/doc/handbook/updating-upgrading-freebsdupdate.html The upgrade borked. Error message: Can't find 'kernel' When I checked with ls /boot/kernel/, the directory does exist. :-( Since the system has encrypted root partion with ZFSonROOT, I tried to follow instructions at https://forums.freebsd.org/viewtopic.php?&t=8958 to boot

Hi, I am using the LLVM release_37 branch and have a strange issue. Please see the two IR outputs I have saved below: https://github.com/dibyendumajumdar/ravi/tree/master/ravi-tests/comp_issue The original.ll is the code I am generating. The aftercompiling.ll is the output from LLVM with opt level 0. The issue is that LLVM is deciding to remove the blocks with labels updatei and updatei.64

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

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 Wed, Feb 1, 2017 at 9:19 AM, Michael Kruse <llvmdev at meinersbur.de> wrote: > 2017-02-01 18:07 GMT+01:00 Kostya Serebryany <kcc at google.com>: > > Yes, I used to run clang-fuzzer and clang-format-fuzzer on this bot, but > not > > any more. > > The reason is simple -- the bot was always red (well, orange) and the > bugs > > were never fixed. >

On Sat, Nov 29, 2014 at 08:34:34PM +0100, Dimitry Andric wrote: > On 29 Nov 2014, at 02:48, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Nov 26, 2014 at 07:44:20PM +0100, Dimitry Andric wrote: > ... > >> I would like to propose the following additional patches for 3.5.1. These will already be part of the upcoming clang 3.5.0 import into the FreeBSD 11.0 base

Hello, In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along with some follow-up patches) the PowerPC back end was changed to use types instead of register classes in instruction patterns. This matched similar changes that Jakob made for Sparc in r177835. I've recently come across an

On Wed, Feb 1, 2017 at 8:45 AM, Mehdi Amini <mehdi.amini at apple.com> wrote: > > > On Feb 1, 2017, at 8:34 AM, Michael Kruse via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > Hi all, > > > > The blog entry [1] suggest that one of the buildbots constantly fuzzes > > clang and clang-format. However, the actual bot [2] only tests the

Hi Dan, I am trying to understand the change you made in http://llvm.org/viewvc/llvm-project?view=revision&revision=57465 In order to understand the details, I tried to revert the change but the test case still passes which is not very surprising after 6 years :(. I am seeing a related new bug that causes a load that was stashed on the NodeStack and in RecordedNodes during iSel to get