search for: clang3.8

Hi, Please find attached a short c test program which does not behave correctly with clang 3.9. I'm running ubuntu 16.04 64bit clang bug.c ./a.out for gcc 5.4.0 / clang3.8 output: 1 1 0 1 1 1 0 1 ./a.out for clang3.9 output: 0 0 0 0 0 0 0 0 Is that a regression? Regards, Christophe -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi All- As we all know, the C++14 discussion is flaring up again. Chandler brought up that he would like a concrete plan to switch. In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release. Instead, I would prefer us to have a concrete Policy on our host compilers. That way, changes like this are unsurprising to our users, and advance our

I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5. On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi All- > As we all know, the C++14 discussion is flaring up again. Chandler > brought up that he would like a concrete plan to switch. In my opinion, > this is insufficient, as it will result in us simply

I've heard just about zero opposition to this, so I've put a code review together here: https://reviews.llvm.org/D47073 With the intent of either implementing this policy change, or encouraging further discussion/bikeshed. Thanks all! -Erich -----Original Message----- From: Brooks Davis [mailto:brooks at freebsd.org] Sent: Sunday, May 13, 2018 10:34 AM To: Keane, Erich <erich.keane

On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev wrote: > Hi All- > As we all know, the C++14 discussion is flaring up again. Chandler brought up that he would like a concrete plan to switch. In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release. Instead, I would prefer us to have a concrete Policy on our host

Based on my reading of the release pages (https://gcc.gnu.org/releases.html and http://releases.llvm.org/) 6/5 would make GCC 4.7 and Clang 3.1 required, and GCC 4.8 and Clang 3.3 the first to not warn. 6/5 is surprisingly close to making the policy conform to exactly our current time-lag, where we are GCC4.8 (instead of 4.7) and Clang 3.1 (also 3.1). -Erich From: Andrew Kelley

I’d like us to move forward with something along the lines Erich proposed back in May, ideally early enough in the LLVM 8 release process that people testing the release will be able to provide feedback. Are there any remaining concerns? > On May 23, 2018, at 6:21 AM, Keane, Erich via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all- > I just wanted to bump this again,

> On Jan 10, 2019, at 4:30 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > > I'm a bit puzzled as of why would a fix period of time be the best option to automatically cut support for older compilers? > > Historically I believe we've been looking at a combination of: > > 1) What new feature we gain by dropping support for a given version of the compiler >

I'd be opposed to 6/5, given where it would leave us. It's simply hard to see a compelling reason to leave things that long. In particular, given this is about what it takes to produce a binary release of clang/llvm from trunk (and not what it takes to use one), i'd like to see some evidence/argument that using 3/1.5 would actually have a material affect on the number of

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009,

Hi, @Erich, thanks for putting this together :). > On May 11, 2018, at 9:54 AM, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I'd be opposed to 6/5, given where it would leave us. > It's simply hard to see a compelling reason to leave things that long. > > In particular, given this is about what it takes to produce a binary release of