similar to: [LLVMdev] Policy for applying fixes to released branches?

On 10 September 2014 12:46, Roel Jordans <r.jordans at tue.nl> wrote: > Hi there, > > My guess is that such a patch should go into a new dot release becoming > 3.5.1 > > According to [1], new releases get decided on by the 'release manager', I'm > not sure who's the current person to contact for that. Tom Stellard did the previous 3.4.2 release. I'm

On 09/09/2014 01:53 PM, Dan Liew wrote: >> It looks like LLVMConfigLibs was created in r112714 for local use in >> Makefile.rules. The only use outside Makefile.rules is now in >> cmake/modules/Makefile. Teaching cmake/modules/Makefile to do >> a direct invocation would be fine with me. > > Okay. Attached is a patch that does this. Does this work okay for you?

> > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips > > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the > > > > dependencies for these at the moment since they seem to depend on some > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a

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

Hello, disclaimer/ Apologies if this is the wrong llvm/clang mailing list; please, direct me to the right one if needed. /disclaimer I've been experiencing issues with incomplete type info when debugging code generated by clang 3.5.0 from the recent release_35 branch. Generally, the problem manifests itself as the inability to examine any std::string parameter to a function, in either gdb

Hi Anton, It seems that some release branches (e.g. release_30, release_35, and release_36) are missing from the Git mirror for libc++abi. May you help to fix the problem? Thanks. Sincerely, Logan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150201/68faf5d4/attachment.html>

Hello, I've stumbled upon the following behavior in branches/release_35 (as of 218689) under ubuntu 14.04 LTS amd64: whenever I include the (system-wise) gnu iostream header, clang++ stops devirtualizing the following code: #if BREAKAGE_ENSUES #include <iostream> #endif struct Base { virtual int foo() const = 0; }; struct A : Base { int a; A(const int a) : a(a) { } int foo() const

On Wed, Nov 26, 2014 at 10:15:13AM +0000, Daniel Sanders wrote: > > From: Daniel Sanders > > Sent: 25 November 2014 17:39 > > To: Eric Christopher; Tom Stellard > > Cc: LLVM Developers Mailing List (llvmdev at cs.uiuc.edu) > > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1 > > > > > > > > I'd also like to propose the inclusion of

Dear all, Recently I've considering using LIT for my benchmark testing framework, and the only reference for LLVM-LIT is the man page and some READMEs. I don't find any documentations on config, which seems to be quite important to the tool. If I use lit outside LLVM source tree and use on my own test files, LIT marks them as 'unresolved'. So are there any documentations I can

On Sep 9, 2014, at 7:12 AM, Dan Liew <dan at su-root.co.uk> wrote: > This is happening because the ``LLVMConfigLibs`` makefile variable is > empty when used in ``cmake/modules/Makefile``. It is normally set in > Makefile.rules . However if you build with --enable-shared this > variable doesn't get set and so LLVMExports.cmake isn't generated > correctly. > >

On 13 December 2014 at 16:50, Renato Golin <renato.golin at linaro.org> wrote: > Same here... ARMv7 is already up and tested, AArch64 is proving a bit > more complicated due to old libstdc++ on my box. I'm working on it. I'm seeing one error on AArch64's test-suite: SingleSource/UnitTests/Vector/AArch64/aarch64_neon_intrinsics.c:154979:16: warning: implicit declaration of

Hi, I can't reproduce your issue on the LLVM 3.5 release branch or trunk it. Looking at your bug report I think your install is messed up ``` CMake Error at /usr/local/Cellar/llvm/HEAD/share/llvm/cmake/LLVMExports.cmake:6 (set_property): set_property could not find TARGET LLVMSupport. Perhaps it has not yet been created. Call Stack (most recent call first):

Hi all, I can't seem to get the simplest CMakeLists.txt file working from http://llvm.org/docs/CMake.html#embedding-llvm-in-your-project. Do any of the LLVM projects use `find_package(LLVM REQUIRED CONFIG)`? Should I just be using `llvm-config` directly? http://llvm.org/bugs/show_bug.cgi?id=20884 David

On 1 June 2016 at 19:20, Dan Liew <dan at su-root.co.uk> wrote: > It seems there is already a repo for OpenSUSE [2]. We could try to > incorporate support for other distros there are make our own given > that we actually want to support multiple LLVM versions too. Looks like they're all 3.8.0 based... > If you want I could try to hack together a proof of concept using the

Hi all, Running LLVM 3.4 to create a custom pass for OpenCL transformations. I am attempting to GEP into a struct using IRBuilder's CreateStructGEP, but I keep getting this assert: aoc: ../../../../../../compiler/llvm/include/llvm/Instructions.h:703: llvm::Type* llvm::checkGEPType(llvm::Type*): Assertion `Ty && "Invalid GetElementPtrInst indices for type!"' failed.

cB->getType()->getPointerElementType()->dump(); gives: %struct.RB = type opaque2189 x_idx = builder.CreateStructGEP(cB, 0); cB->dump() gives: %struct.RB addrspace(1)* %cB $1 = void //To undo confusion, the last cB is the function arg name. For this example I unfortunately chose the same name for my argument Value* as the argument name. //Also one correction. I am running

If I do M.dump(), at the top of the output I have: %struct.RB = type opaque Further down I have: @.str18 = internal addrspace(2) constant [13 x i8] c"RB_t*\00" However nowhere does it dump the full struct type when I call "M.dump()". I have it explicitly defined above the kernel in the kernel file, but LLVM doesn't seem to pick it up. Opaque is a placeholder until it

I want to start using cmake+ninja instead of autoconf for configuring and building llvm from svn, but I have no idea how to map my existing list of autoconf flags to cmake. Here's how I run ./configure right now in the top directory: PREFIX=_some_prefix_dir_ \ ../llvm/configure \ --prefix=$PREFIX \ --libdir=$PREFIX/lib/llvm \ --sysconfdir=$PREFIX/etc \ --enable-shared \

Sure, it is the Rodinia 2.4 Hotspot benchmark OpenCL kernel (not my kernel), with the addition of my struct as the last argument in the kernel function. //------- kernel file start ------------------------------- #define BLOCK_SIZE 16 //dlowell's type #define BUFFER_LEN 0x100000 typedef struct RB{ unsigned int x; unsigned int y; int z[BUFFER_LEN]; unsigned int xx[BUFFER_LEN];