similar to: [LLVMdev] gmail marking llvm emails as spam? Re:

Hi, I would like to begin the 3.4.2 release process for LLVM. There have been two issues identified in 3.4.1, which there is interest in having fixed in a 3.4.x release: 1. Build failure with gcc 4.9 (This is not a regression, 3.4 also fails to build with gcc 4.9). 2. Accidental change of libLLVM's DT_SONAME from libLLVM-3.4 libLLVM-3.4.1.so I will also accept any other bug-fixes that

On 12/05/2014 17:12, Tom Stellard wrote: > On Mon, May 12, 2014 at 04:17:05PM +0200, Sylvestre Ledru wrote: >> On 12/05/2014 16:13, Tom Stellard wrote: >>> On Mon, May 12, 2014 at 04:05:20PM +0200, Sylvestre Ledru wrote: >>>> On 12/05/2014 15:22, Tom Stellard wrote: >>>>> On Mon, May 12, 2014 at 08:41:36AM +0200, Sylvestre Ledru wrote:

On 12/05/2014 16:13, Tom Stellard wrote: > On Mon, May 12, 2014 at 04:05:20PM +0200, Sylvestre Ledru wrote: >> On 12/05/2014 15:22, Tom Stellard wrote: >>> On Mon, May 12, 2014 at 08:41:36AM +0200, Sylvestre Ledru wrote: >>>> Hello, >>>> >>>> With the release of 3.4.1, the LLVM library has been renamed from >>>> libLLVM-3.4.so to

On 12/05/2014 15:22, Tom Stellard wrote: > On Mon, May 12, 2014 at 08:41:36AM +0200, Sylvestre Ledru wrote: >> Hello, >> >> With the release of 3.4.1, the LLVM library has been renamed from >> libLLVM-3.4.so to libLLVM-3.4.1.so. In parallel, the soname has been >> updated to >> reflect this change. >> >> AFAIK, we kept the ABI compatible from 3.4

Hi, I would like to try again to do stable releases for LLVM 3.4. Even though we were unsuccessful with stable releases for LLVM 3.3, I learned some things going through the process, which I think will increase the chance for success with LLVM 3.4. So, here is my TODO list for a successful 3.4.1 release: 1. Get volunteers to help This is probably the most important thing on this list. Stable

Hello, With the release of 3.4.1, the LLVM library has been renamed from libLLVM-3.4.so to libLLVM-3.4.1.so. In parallel, the soname has been updated to reflect this change. AFAIK, we kept the ABI compatible from 3.4 to 3.4.1. So, is there any reason for doing it? This caused some breakages in Debian (basically, breaking some X because of mesa could not link against LLVM due to the new soname).

Hi Tom, When running the test script, I got an error message: $ ./test-release.sh -no-64bit -release 3.4.2 -rc 1 -triple armv7a-linux-gnueabihf -j2 # Validating llvm SVN URL llvm 3.4.2 release candidate rc1 doesn't exist! Do I need to get another test-release.sh script? This is the one from release_34 branch we used to release 3.4.1. cheers, --renato On 16 May 2014 22:55, Tom Stellard

On Mon, Nov 3, 2014 at 9:26 AM, Tom Stellard <tom at stellard.net> wrote: > On Fri, Oct 31, 2014 at 04:31:47PM -0700, Bob Wilson wrote: > > > > > On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com> > wrote: > > > > > > > > > > > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net >

I committed: r224058 = 966942da9e68b59c31ce770e7f94c55a63482c6b r224060 = da75f7277e3a129aed8ef8aa4e0d84de40b76fd4 r224061 = f88e4c8e9171045454b2c8e05054c2af8da3fe4f Let me know if somehow you're still hitting the problem. r224061 removes leak detection entirely from `MachineInstr`. There aren't any leaks to be had there, since they're allocated in a custom allocator. They're

> On 2014 Dec 10, at 14:08, Tom Stellard <tom at stellard.net> wrote: > > On Wed, Dec 10, 2014 at 11:21:08AM -0800, Duncan P. N. Exon Smith wrote: >> >>> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: >>> >>> On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >>>> The `Metadata`/`Value`

On Wed, Dec 10, 2014 at 05:27:45PM -0800, Duncan P. N. Exon Smith wrote: > +zalman at google.com > Hi Duncan, This patch plus another small change fixes the assertion failure for me. With the patch alone, the void* overload of addGarbageObject() was being used by MDNode::getTemporary(), so I had to cast the object as an MDNode*: diff --git a/lib/IR/Metadata.cpp b/lib/IR/Metadata.cpp

> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the >> C++ side of it. This was a rocky day, but I suppose that's what I get >> for failing to stage the change in smaller pieces. >>

On Thu, 15 May 2014 02:25:30 +0200, Tom Stellard wrote: > On Sat, May 10, 2014 at 11:48:23PM +0200, Tuncer Ayaz wrote: > > Tom, > > > > now that 3.4.1 is out, any chance of a 3.4.2 with just the three > > fixes or at least merging them to the 3.4 branch? > > I've pushed the two approved patches to the 3.4 branch, can you > verify that they work with gcc

> On Oct 31, 2014, at 4:19 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Fri Oct 31 2014 at 3:11:22 PM Tom Stellard <tom at stellard.net <mailto:tom at stellard.net>> wrote: > Hi, > > I would like to propose deprecating the autoconf build system at some > point in the future. Maintaining two build systems is a hassle not > only

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

On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote: > On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote: > > 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

On Wed, 2019-02-06 at 14:09 -0800, Tom Stellard wrote: > On 02/05/2019 10:41 PM, Michał Górny wrote: > > On Tue, 2019-02-05 at 16:13 -0800, Tom Stellard wrote: > > > On 02/05/2019 11:32 AM, Tom Stellard via Release-testers wrote: > > > > 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 >> version and pushed a fix for https://bugs.llvm.org/show_bug.cgi?id=39427, >> which is the only bug we will be fixing in this release. >> >>

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

Hi, I would like to propose deprecating the autoconf build system at some point in the future. Maintaining two build systems is a hassle not only for this project, but also for other projects that use LLVM and have to deal with the slight differences in output between the two build systems. It seems like most people are using CMake at this point, so my questions to the community are: - Is