similar to: [RFC] migrating past C++11

+1, thanks again for driving this. On Fri, Jan 25, 2019 at 3:57 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The discussion seems to have died down and gotten good consensus. I’ve > therefore create a patch which applies the proposed soft-errors: > > https://reviews.llvm.org/D57264 > > > We’ll only migrate to hard-error (and start using new

On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hello folks (except fans of April 1st: this is *not* a joke), > > We discussed migrating past C++11 > <http://lists.llvm.org/pipermail/llvm-dev/2019-January/129452.html> recently > and got consensus. This led us to bump our minimum toolchain requirements >

> On Apr 1, 2019, at 4:10 PM, JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > >> On Apr 1, 2019, at 4:07 PM, Chandler Carruth <chandlerc at gmail.com <mailto:chandlerc at gmail.com>> wrote: >> >> On Mon, Apr 1, 2019 at 1:16 PM JF Bastien via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>

> On May 6, 2019, at 11:02 AM, Chandler Carruth <chandlerc at gmail.com> wrote: > > I know you'll be shocked that we've slipped in our efforts. ;] I don't have a super meaningful ETA update though -- a bunch of unknows have been found and addressed, and again, I feel like we might finish this in roughly a month. > > On the flip side, I do want to clarify the

On Mon, May 6, 2019 at 2:44 PM James Y Knight <jyknight at google.com> wrote: > Given the small number of library features added by c++14, and given that > they were mostly already implemented in libstdc++ 4.9 [1], I suspect that > moving to c++14 with that stdlib as the minimum probably will not actually > cause friction for developers who are using normal toolchains to be able

I'm happy to announce that Google has migrated to libc++, and we're ready for C++14 and beyond. JF, what are the remaining blockers? /Eric On Mon, May 6, 2019 at 5:12 PM JF Bastien via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On May 6, 2019, at 2:08 PM, Chandler Carruth <chandlerc at gmail.com> wrote: > > On Mon, May 6, 2019 at 2:44 PM James Y

If you're interested in the evolution of C++'s memory model, here are some papers on the topic: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2664.htm http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2429.htm http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html A working draft for the next C++ standard is also available:

Hello, I just discovered, that, when using enable_shared_from_this and inheriting it privately, this fails at runtime. I made a small example: #include <memory> #include <boost/shared_ptr.hpp> #include <boost/make_shared.hpp> #include <boost/enable_shared_from_this.hpp> #ifndef prefix #define prefix std #endif class foo: prefix::enable_shared_from_this<foo> {

Am 29.08.19 um 12:07 schrieb Jonathan Wakely: > On Thu, 29 Aug 2019 at 10:15, Christian Schneider > <cschneider at radiodata.biz> wrote: >> >> Hello, >> I just discovered, that, when using enable_shared_from_this and >> inheriting it privately, this fails at runtime. >> I made a small example: >> >> #include <memory> >> #include

Hi all, This is just a PSA that as of r302752, 3 parallel algorithms (for_each, for_each_n, and sort) are available in llvm/Support/Parallel.h. Effort was made to match the C++ Parallelism TS N4507 [ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4507.pdf] as closely as possible, but some aspects were intentionally omitted. No support is added for the executor proposal N4406 [

It's hard to say. By definition it appears undefined (in the sense that the TS literally does not define it), but on the other hand it is a TS and this issue would (hopefully) come up and be specified before it made it to standardization. Supporting recursive parallel calls certainly seems like desirable behavior, so from my point of view it would be nice to make sure it works. Not sure if

On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > > On Nov 14, 2009, at 3:16 PMPST, Howard Hinnant wrote: > >> In many places there is code that looks like: >> >> MBBI = next(MBBI); >> >> In C++0X there is a std::next that is likely to be in scope when these >> calls are made. And due to ADL the above call becomes ambiguous: >>

On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > I don’t have the C/C++ standards in front of me but IIRC whether a char/short/int/long/long long bitfield is signed or unsigned is implementation defined. You need to explicitly specify signed or unsigned in order to have any guarantee of the signedness, e.g. signed int. Section 3.9.1 of the C++11 standard [1]

Howard Hinnant wrote: > On Nov 16, 2009, at 1:43 PM, Dale Johannesen wrote: > > >> "next" is a popular name; if it breaks llvm, I'd expect this standards change to break a lot of existing code. Do you really want to do that? >> > > I'm happy to open an LWG issue for you on this subject. Here are directions on submitting an issue: > >

Hi, I’ve made my own version of std::vector which is called il::Vector. Due to http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3664.html>, LLVM can optimise away memory allocation. Therefore, the following code optimise away all memory allocation for w resulting in a single allocation during the whole program (for

Hi Mon Wang, As I understand it the C++0x memory model will, by default, be similar to Java's in that it will assume sequential consistency, using acquire/release atomics (similar to Java's volatile), for all programs that do not contain data races. Unlike Java in the case when a program contains a data race, the program behavior is undefined. Adopting this model allows many sequential

C says that plain bit-fields could be either signed or unsigned. C++ removed this allowance in core issue 739: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#739 On Sat, Nov 16, 2013 at 1:55 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote: > On 2013 Nov 15, at 19:41, Mark Lacey <mark.lacey at apple.com> wrote: > > > I don’t have the C/C++

On Mar 19, 2014, at 11:32 AM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Wed, Mar 19, 2014 at 2:13 PM, Lang Hames <lhames at gmail.com> wrote: >> Hi all, >> >> As RFCs go this is short and sweet - I think it would be nice to add an >> empty method to iterator_range. Something like: >> >> bool empty() const { return begin() != end();

Hi Kevin, On April 11, 2017 at 4:14:14 PM, Flamedoge (code.kchoi at gmail.com) wrote: > So only "non-freed" malloc pointers are No-Alias which makes it > flow-sensitive. There is no reason why malloc couldn't return previously > freed location. Yes. Talking to Nick Lewycky on IRC, I figured out a shorter way of saying what I wanted to say.  We know that programs like this

Hi John, It seems the dereferencing a NULL pointer is undefined behavior but Calling a function through a null pointer seems o.k. If so , for this place, we need comment out the check. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#232 look at Notes from the October 2003 meeting. Yin From: John Criswell [mailto:criswell at illinois.edu] Sent: Wednesday,