similar to: Distinguishing trunk version number from release

On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'd like to propose that trunk always have a version number which is in between versions used by the previous release branch, and before the versions used in the next release branch. > > Right now, trunk is sharing the 7.0.0 number, which will also be used by the next release 4

On 01/03/2018 09:24 AM, James Y Knight via llvm-dev wrote: > I'd like to propose that trunk always have a version number which is in between versions used by the previous release branch, and before the versions used in the next release branch. > > Right now, trunk is sharing the 7.0.0 number, which will also be used by the next release 4 months from now. Since some people use and

On Thu, Jan 4, 2018 at 3:04 PM, Dimitry Andric <dimitry at andric.com> wrote: > On 3 Jan 2018, at 18:24, James Y Knight via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > > > I'd like to propose that trunk always have a version number which is in > between versions used by the previous release branch, and before the > versions used in the next release

On 01/03/2018 11:25 AM, James Y Knight via llvm-dev wrote: > On Wed, Jan 3, 2018 at 12:24 PM, James Y Knight <jyknight at google.com > <mailto:jyknight at google.com>> wrote: > > I'd like to propose that trunk always have a version number which > is in between versions used by the previous release branch, and > before the versions used in the next

On Wed, Jan 3, 2018 at 12:24 PM, James Y Knight <jyknight at google.com> wrote: > I'd like to propose that trunk always have a version number which is in > between versions used by the previous release branch, and before the > versions used in the next release branch. > Oops, I misphrased that -- I meant to say "which is *after* versions used by the previous release

I agree with Hal, X.99 is easier to notice as something different/unusual. It also doesn't revisit the version-naming debate for formal releases. --paulr From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Hal Finkel via llvm-dev Sent: Wednesday, January 03, 2018 11:24 AM To: James Y Knight; llvm-dev Subject: Re: [llvm-dev] Distinguishing trunk version number from release

On 01/03/2018 12:55 PM, Tom Stellard via llvm-dev wrote: > On 01/03/2018 09:24 AM, James Y Knight via llvm-dev wrote: >> I'd like to propose that trunk always have a version number which is in between versions used by the previous release branch, and before the versions used in the next release branch. >> >> Right now, trunk is sharing the 7.0.0 number, which will also be

I saw an email about 8.0.1 being not quite out, and planning for 9.0.0. When is 8.0.1 supposed to come out? I installed llvm at develop on x86 on March 30, and its clang says it is version 9.0.0 (trunk 357348). I tried to do another spack install llvm at develop, but it said that I already had it installed. Does that mean there were no changes since March 30, or does spack not look for any

Hey Guys, I'm working on a project in Android related to System-level Audio DSP Effects for Tuning Android Audio. I want to leverage Faust ( https://faust.grame.fr/) to allow users to program their own filters. Faust provides a libfaust implementation which includes a JIT Compiler which leverages LLVM and seems to be the best path for me to use. Unfortunately I'm having problems

I was wondering if anyone has encountered this issue when cross compiling cuda on Nvidia TX2 running android. The error is In file included from <built-in>:1: In file included from prebuilts/clang/host/linux-x86/clang-4667116/lib64/clang/7.0.1/include/__clang_cuda_runtime_wrapper.h:219: ../cuda/targets/aarch64-linux-androideabi/include/math_functions.hpp:3477:19: error: no matching function

Hi, Fixing http://llvm.org/PR39427 in the release_70 branch, will change the ABI of a clang built libLLVM-7.so so that it is no longer compatible with the 7.0.0 release. libLLVM-7.so built by gcc will not be affected by this fix. Changing the ABI is something we aren't supposed to do in stable releases, but this fixes an ABI difference between clang and gcc built libLLVM-7.so that is

+Artem Belevich <tra at google.com> On Fri, Mar 23, 2018 at 7:53 PM Bharath Bhoopalam via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I was wondering if anyone has encountered this issue when cross compiling > cuda on Nvidia TX2 running android. > > The error is > In file included from <built-in>:1: > In file included from >

On Mon, Sep 9, 2019 at 8:25 PM Hans Wennborg <hans at chromium.org> wrote: > On Fri, Sep 6, 2019 at 6:17 PM Björn Pettersson A via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I'm a little bit curious to hear more about the experiences from the > changes in LLD. > > I’m thinking about things like: > [..] > > - merging of bugfixes to older

Hypothetically assume that we have an LLVM release X and want to rename variables in the next major release Y. In order to backport patches from Y to X.1 smoothly, I think we could first apply the automated renaming tool to X and then cherry-pick patches from Y. The obvious issue of doing this is, even though X.1 is a dot release, a very large number of lines would be changed from X, though. On

Hi, I'm trying to compile some apps with the new llvm-gcc4 on amd64 linux to .bc files, rather than to the native code. The same process I used to build those apps before with llvm-gcc3 doesn't work: 1) export CC=llvm-gcc CXX=llvm-g++ CFLAGS="-g -fno-inline" CXXFLAGS="-g -fno-inline" 2) cd <whatever-app>; ./configure 3) make CFLAGS+=-emit-llvm

It's my great pleasure to announce that LLVM 9 is now available. Get it here: https://llvm.org/releases/download.html#9.0.0 This release is the result of the LLVM community's work over the past six months (up to trunk r366426 plus commits on the branch). Some highlights include: - Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang - The

It's my great pleasure to announce that LLVM 9 is now available. Get it here: https://llvm.org/releases/download.html#9.0.0 This release is the result of the LLVM community's work over the past six months (up to trunk r366426 plus commits on the branch). Some highlights include: - Support for asm goto, enabling for example the mainline Linux kernel for x86_64 to build with Clang - The

On 12/12/2018 08:53 PM, James Y Knight via llvm-dev wrote: > On Fri, Nov 16, 2018 at 7:40 PM Jeremy Lakeman <Jeremy.Lakeman at gmail.com <mailto:Jeremy.Lakeman at gmail.com>> wrote: > > Semantic versioning would recommend "v8.0.0-dev", "v8.0.0-rc1" etc. The hyphen indicating that this is a pre-release version coming before "v8.0.0" > >

Hi, I've tagged the 8.0.1-rc1 release. Testers, please begin testing and upload the binaries. If you still want to have a bug fix included in the 8.0.1 final release you have until June 6 to request a fix be backported to the releases/8.0 branch. To make a request, file a bug at bugs.llvm.org and put release-8.0.1 into the 'Blocks:' field. You can also use the

Hats off to the Android NDK team! http://developer.android.com/tools/sdk/ndk/index.html Important changes: * Added the Clang 3.1 compiler to the NDK. The GNU Compiler Collection (GCC) 4.6 is still the default, so you must explicitly enable the Clang compiler option as follows: * For ndk-build, export NDK_TOOLCHAIN_VERSION=clang3.1 or add this environment variable setting