similar to: [7.0.0 Release] Schedule proposal

If you are on glibc-2.24, did you patch it with the fix 24e2b1cede1952d7d4411a3cafd25dd8593dab9f that revert commits 80f87443eed17838fe453f1f5406ccf5d3698c25 and a824d609581d5ee7544aabcbbc70e8da44b2b5b6? I had to do that since it broke go, gcc, and clang address sanitizers without the patch. On 9/12/16, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On 11 September

Hello testers, 5.0.0-rc4 was just tagged. There were very few changes after rc3, and if nothing unexpected comes up, this is what the final release will look like. Please test and let me know if there are any issues. Cheers, Hans

Hello everyone, The release branch for LLVM 9 and its sub-projects was just created from trunk at r366426, and the trunk version was subsequently bumped to 10.0.0. Release blockers are tracked by https://llvm.org/PR42474 Please mark any bugs, old or new, that need to be fixed before the release as blocking that. To get a change committed to the branch, first commit it to trunk as usual, and

Has it been decided to skip 3.7.1 and just wait until 3.8.0? I keep checking but never see any update on the web site to allow downloading 3.7.1 tar files.

Maybe it's just the holidays... AFAIK, all the packages were tested and uploaded. On 29 December 2015 at 22:44, Martin J. O'Riordan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Got to admit, I'm curious too. I have finished migrating to the v3.7.1-final tags, and I'm waiting for the green light :-) > > MartinO > > -----Original Message----- >

On Mon, Nov 4, 2019 at 4:00 PM James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > To throw my hat into the ring, we also maintain a downstream target that > has a subset of this problem - it has non-8-bit-addressable memory. This > means that %uglygeps don't work, pointers can't be casted to i8* and expect > to be byte-addressed (conversions to

On Sat, Nov 2, 2019 at 12:45 AM Jorg Brown via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Nov 1, 2019 at 8:40 AM Adrian Prantl via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> > On Nov 1, 2019, at 3:41 AM, Dmitriy Borisenkov via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> > It seems that there are two possible

Hello, The llvm.org web site says the release would be in mid-june. There was a message posted to the dev list that 3.8.1 was tagged. Then there was another message that said essentially "don't make your own tarballs - wait for release tarballs". I have two questions: 1. If the 3.8.1 tag does not represent what will be the tarball contents, will the tag be moved when the

Hi David, I agree with you that it would be rude to simply clang-format the MIPS backend without coordination with any out-of-tree derivatives. To be honest, it hadn't occurred to me that there would be any such derivatives and the possibility wasn't raised in our internal discussion before we brought the subject up on this list. I'm keen to coordinate with such derivatives to

Yeah, I see. You have an unusual development process seen from my POV. IMHO you can provide the tarballs before the "binaries" are uploaded which means "prebuilt binaries". That could increase the quality of developing when different arch/os maintainers give their OK. But for 7.0.0rc1 I see only prebuilt binaries for... * macOS * FreeBSD10 AMD64 * Windows (32-bit) * Windows

Hi llvm-dev We have not been able to complete all the work we need to do before merging F18 into LLVM as Flang so we will not be dong that today as previously announced. We propose to slip this back a week to let us finish off the last bits of work. All code changes are in review as of Friday. If you want more detail, you can see the exact status here:

Hi Hans, we have uploaded tarballs for ARM and AArch64 targets: a20ea3fe482e754a61ccb37c67456ad1 clang+llvm-6.0.1-aarch64-linux-gnu.tar.xz f37b132c3dfb3b776524980be5af3a76 clang+llvm-6.0.1-armv7a-linux-gnueabihf.tar.xz and 47a9a9bb02d41581e6804b98918188f6 clang+llvm-7.0.0-aarch64-linux-gnu.tar.xz e639d8f5dc58be5cf44d017fd5eefd6c clang+llvm-7.0.0-armv7a-linux-gnueabihf.tar.xz Yvan On Mon,

Folks, There has been enough discussion about keeping development downstream and how painful that is. Even more so, I think we all agree, is having downstream releases while tracking upstream releases, trunk and other branches (ex. Android). I have proposed "en passant" a few times already, but now I'm going to do it to a wider audience: Shall we sync our upstream release with the

FWIW, I don't have really strong objections, but I'm honestly not a fan. The reason is mostly that I think it is very late to make the change and likely to mean most people are on holiday when the branch occurs. I somewhat anticipate significantly more cherrypicks as a consequence. I'd love for Apple's releases to by sync'd with the open source ones, but I don't understand

Hi everyone, A couple of weeks ago I noticed a bug with :dependent => :nullify on a has_many or has_one. When you delete the parent, the children''s foreign keys are nullified, as expected. But when you do parent.child.delete or parent.children.clear, ActiveRecord actually deletes the child records, rather than just nullifying them. In my eyes, if you''ve set

On Fri, Jan 11, 2013 at 3:47 PM, Pawel Wodnicki <root at 32bitmicro.com> wrote: > On 1/11/2013 2:40 PM, Brooks Davis wrote: > > On Fri, Jan 11, 2013 at 09:33:17PM +0100, Benjamin Kramer wrote: > >> > >> On 11.01.2013, at 21:31, Justin Holewinski > >> <justin.holewinski at gmail.com> wrote: > >> > >>> On Fri, Jan 11, 2013 at 3:26

Hi, We don't normally do X.Y.2 releases, but there has been some interest in getting a 5.0.2 release out with the Spectre mitigations included, so I am proposing the following schedule for a 5.0.2 release: LLVM 5.0.2 -rc1 Mon Mar 19 -final Mon Mar 26 To keep things easy for testers, 5.0.2 will be for Spectre related fixes only and won't be opened up for general bugs. And here is

Dear testers, 7.0.0-rc2 was just tagged (from branch revision r340437). There have been a bunch of merges since rc1, and hopefully many of the issues with the previous candidate are fixed in this one. Please run the test script, share the results, and upload binaries. I will publish source tarballs, docs, and binaries on the web page once they're ready. Thanks, Hans

We are having line noise issues in our Asterisk to legacy PBX integration. All SIP calls originating from IP phones sound crystal clear. All calls that originate from the legacy PBX (Isoetec 228) and route through the Asterisk and out SIP have a lot of line noise. I believe I have it pinned down to these Blue Alarm errors that I can see on the legacy PBX side. zttool shows no alarm but when I

In llvm/lib/CodeGen/AsmPrinter/DwarfUnit.cpp, the compiler can emit a DW_AT_calling_convention attribute with a DW_TAG_class_type (and it looks like a DW_TAG_variant_part, DW_TAG_structure_type or DW_TAG_union_type as well), but the DWARF 4 specification says that DW_AT_calling_convention is not a valid attribute for any of those three DWARF tags. Downstream object consumers that check to verify