similar to: [LLVMdev] question about llvm C++ standard?

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 fans of the auto keyword! We now have a policy on how LLVM toolchains get updated <https://reviews.llvm.org/rL351765>! Let’s put that policy to good use, and talk about how we’ll move all monorepo projects past C++11. Previous Discussions LLVM dev meeting 2018 BoF "Migrating to C++14, and beyond! <http://llvm.org/devmtg/2018-10/talk-abstracts.html#bof3>" A Short

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 [

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 >

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

+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 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 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: > >

> 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

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 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,

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: > llvm::next or std::next? > > I recommend: > > MBBI = llvm::next(MBBI); > > -Howard

On 13/09/2018 18:22, David Blaikie via llvm-dev wrote: > On Thu, Sep 13, 2018 at 12:13 AM Dávid Bolvanský via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > /home/davidbolvansky/trunk/llvm/unittests/ExecutionEngine/Orc/CompileOnDemandLayerTest.cpp:79:40: >  required from here >

Hello, I think there's a rather subtle problem with the inst_iterator. It declares its iterator category as std::bidirectional_iterator_tag but C++ standard requirements for forward iterator (which are included in requirements for bidirection iterator), say that the type of expression *r; should be T&, where 'r' is the iterator and T is its value type. The inst_iterator,