similar to: [LLVMdev] 3.2 version string

Jeff Bezanson <jeff.bezanson at gmail.com> writes: > LLVM 3.2 came as a nice Christmas present. Just one minor question: I > noticed that the version string (used to name the shared library etc.) > is "3.2svn" instead of the expected "3.2". This violates our build > system's expectations of what things are called. It would be easy for > us to change,

Signed-off-by: Sedat Dilek <sedat.dilek at gmail.com> --- CMakeLists.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CMakeLists.txt b/CMakeLists.txt index ed7aeb026f5d..60fe427e456e 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -66,7 +66,7 @@ set(LLVM_VERSION_PATCH 0) set(LLVM_VERSION_SUFFIX svn) if (NOT PACKAGE_VERSION) - set(PACKAGE_VERSION

LGTM. -Chris > On Feb 27, 2015, at 3:27 AM, Sedat Dilek <sedat.dilek at gmail.com> wrote: > > Signed-off-by: Sedat Dilek <sedat.dilek at gmail.com> > --- > CMakeLists.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/CMakeLists.txt b/CMakeLists.txt > index ed7aeb026f5d..60fe427e456e 100644 > --- a/CMakeLists.txt > +++

[ Please CC me I ma not subcribed to this mailing-list ] [ CC Tom and Hans as LLVM/stable maintainers ] Hi, I want to understand the version handling in LLVM/Clang/LLD. Normally, I build from "release/10.x" Git branch by using the tool tc-build from ClangBuiltLinux project. With "llvm-10.0.1-rc1" Git tag I was able to setup a llvm-toolchain consisting of the projects

On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/19/2020 09:05 PM, Sedat Dilek wrote: > > Hi Tom, > > > > thanks and congrats for LLVM 10.0.1-rc1 release. > > > > [1] shows 2 assets. > > 10.0.0 RCs had a lot of more assets. > > I am missing the llvm-project-10.0.1rc1.tar.xz tarball. > > > > Will

Hi Tom, thanks and congrats for LLVM 10.0.1-rc1 release. [1] shows 2 assets. 10.0.0 RCs had a lot of more assets. I am missing the llvm-project-10.0.1rc1.tar.xz tarball. Will you provide them later or is there a new development/workflow decision I do not know of? BTW, the source zip and tar.gz tarballs show no sizes. I am using Mobile LTE/UMTS to download stuff from the Internet. For now I

On Wed, May 20, 2020 at 11:12 PM Tom Stellard <tstellar at redhat.com> wrote: > > On 05/20/2020 09:53 AM, Sedat Dilek wrote: > > On Wed, May 20, 2020 at 5:06 PM Tom Stellard <tstellar at redhat.com> wrote: > >> > >> On 05/19/2020 09:05 PM, Sedat Dilek wrote: > >>> Hi Tom, > >>> > >>> thanks and congrats for LLVM

On Sun, Jun 26, 2016 at 2:48 PM, Renato Golin <renato.golin at linaro.org> wrote: > On 26 June 2016 at 13:31, Anton Korobeynikov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> What you're probably missing is that 3.8.1 is made in release_38 >> branch. So, everything is there and already mirrored. >> >> Source tarballs will be available upon the

On 26 June 2016 at 13:31, Anton Korobeynikov via llvm-dev <llvm-dev at lists.llvm.org> wrote: > What you're probably missing is that 3.8.1 is made in release_38 > branch. So, everything is there and already mirrored. > > Source tarballs will be available upon the release. Which are just coming, now that final has been tested successfully. :) They'll be announced in the

Just in case someone is having similar problems and/or following this thread, here's my final "solution" (at least, for now). In my bash build script, prior to configure, I set the C_INCLUDE_PATH and CPLUS_INCLUDE_PATH to empty strings, and then set some other environment variables instead: export C_INCLUDE_PATH= export CPLUS_INCLUDE_PATH=

I'm continuing this here in llvm-dev since the thread was started here, but, in hindsight, it may have been better in cfe-dev, because the problem seems to be related to clang. I turned on "verbose" mode in make (VERBOSE=1 TOOL_VERBOSE=1) and found that it is clang, not gcc, that is being used at this point in the make. Based on the command issued (particularly with the --sysroot

Hi everyone, I just reported the following issue: https://llvm.org/bugs/show_bug.cgi?id=24927 Using the Xcode 7 linker, one gets messages such as the following when linking objects generated using llvm: ld: warning: object file (foo.o) was built for newer OS X version (14.5) than being linked (10.9) The issue is the following: a) In lib/Support/Unix/Host.inc, sys::getDefaultTargetTriple()

A division intrinsic with defined behavior on all arguments would be awesome! Thanks for considering this. On Sat, Apr 6, 2013 at 11:27 AM, Joe Groff <arcata at gmail.com> wrote: > On Saturday, April 6, 2013, Jeff Bezanson wrote: >> >> >> Presumably the optimizer benefits from taking advantage of the >> undefined behavior, but to get a consistent result you need

The usual procedure is to make time-based releases. So - "release trunk and make sure it's stable enough" plus - fix any outstanding regressions. There is some text wrt this: http://llvm.org/docs/HowToReleaseLLVM.html#release-qualification-criteria On Fri, Dec 13, 2013 at 11:08 AM, "C. Bergström" <cbergstrom at pathscale.com> wrote: > On 12/13/13 01:58 PM, Bill

On 12/13/13 01:58 PM, Bill Wendling wrote: > That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to

I'm attempting to build a native build of clang from the 3.2 source distribution tarballs, but I ran into this build error that's got me really puzzled. My platform is Linux - 32-bit Ubuntu (12.04) running on a PC. Here's the (abbreviated) output from make: *************************************** ... make[3]: Entering directory

On Sat, Apr 6, 2013 at 3:22 PM, Jeff Bezanson <jeff.bezanson at gmail.com>wrote: > A division intrinsic with defined behavior on all arguments would be > awesome! Thanks for considering this. 'Tis a good compromise. If there are no objections/concerns, I would like to move forward with it. Thanks, Joe! -Cameron -------------- next part -------------- An HTML attachment was

Is this supported? I have a very simple setup where I have 2 X100P cards and a TDM10B. The TDM10B is connected to a phone that has a digital answering machine built into it. If I make an inbound call on either X100P interface it gets transferred to the TDM10B interface. If I let it ring the TDM10B interface answers the call and the greeting message of the answering machine starts. Then shortly

That’s a long laundry list of bugs there. It would be great to have them fixed, but the reality of the situation is that they won’t be fixed for weeks or more, if at all. And with Christmas coming up, it makes things even worse. There are a few days before Phase III starts to have some progress on them. But if they don’t make it, then we’ll have to release without them. -bw On Dec 12, 2013, at

On 02/05/2019 11:26 AM, Michał Górny wrote: > On Tue, 2019-02-05 at 11:23 -0800, Tom Stellard wrote: >> On 02/05/2019 08:07 AM, Michał Górny wrote: >>> On Tue, 2019-02-05 at 07:36 -0800, Tom Stellard via Release-testers >>> wrote: >>>> Hi, >>>> >>>> The release_70 branch is ready for the 7.1.0 release. I have updated the