search for: wg21

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: http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2461.pdf (It incorporates s...

...is official by creating a patch which will: > > > - Update the C++ standard version > <http://llvm.org/docs/CodingStandards.html#c-standard-versions> to > C++14, allowing the usage of the following language and library features: > - Binary literals <https://wg21.link/N3472>: > - Without restrictions. > - decltype(auto) <https://wg21.link/N3638>, Return type deduction > for normal functions: > - As with auto > <http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-mor...

...sting that we make this official by creating a patch which will: >> >> Update the C++ standard version <http://llvm.org/docs/CodingStandards.html#c-standard-versions> to C++14, allowing the usage of the following language and library features: >> Binary literals <https://wg21.link/N3472>: >> Without restrictions. >> decltype(auto) <https://wg21.link/N3638>, Return type deduction for normal functions: >> As with auto <http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>, only where it makes code mo...

...e make this official by creating a patch which will: >>> >>> Update the C++ standard version <http://llvm.org/docs/CodingStandards.html#c-standard-versions> to C++14, allowing the usage of the following language and library features: >>> Binary literals <https://wg21.link/N3472>: >>> Without restrictions. >>> decltype(auto) <https://wg21.link/N3638>, Return type deduction for normal functions: >>> As with auto <http://llvm.org/docs/CodingStandards.html#use-auto-type-deduction-to-make-code-more-readable>, only where it m...

...r toolchains: they don’t even support C++11 very well. We have a handful of workarounds left in ADT (particularly around type traits) and I’d like to get rid of them. The compiler versions I propose allow us to use all of C++14, which includes: Binary literals <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf> decltype(auto), Return type deduction for normal functions <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html> Initialized/Generalized lambda captures (init-capture) <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3648.html> Gene...

...;> >>>> - Update the C++ standard version >>>> <http://llvm.org/docs/CodingStandards.html#c-standard-versions> to >>>> C++14, allowing the usage of the following language and library features: >>>> - Binary literals <https://wg21.link/N3472>: >>>> - Without restrictions. >>>> - decltype(auto) <https://wg21.link/N3638>, Return type >>>> deduction for normal functions: >>>> - As with auto >>>> <http://llvm.org/docs/C...

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 [ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf], but I plan to try to work on this in the future, with no specified timeline. --...

...t;>> - Update the C++ standard version >>>>> <http://llvm.org/docs/CodingStandards.html#c-standard-versions> to >>>>> C++14, allowing the usage of the following language and library features: >>>>> - Binary literals <https://wg21.link/N3472>: >>>>> - Without restrictions. >>>>> - decltype(auto) <https://wg21.link/N3638>, Return type >>>>> deduction for normal functions: >>>>> - As with auto >>>>> <ht...

...t; >> 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 [ >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4406.pdf], but >> I plan to try to work on this i...

...; "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: http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue Please don't hesitate to ask me if these directions aren't clear (I'll likely update the directions from your feedback). Here is a link to the latest C++0X draft that your issue will be directing the LWG to modify: http://www.open-std.org/jtc1/sc22/w...

...1 very well. We have a handful of workarounds left in ADT (particularly > around type traits) and I’d like to get rid of them. > > The compiler versions I propose allow us to use all of C++14, which > includes: > > - Binary literals > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf> > - decltype(auto), Return type deduction for normal functions > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3638.html> > - Initialized/Generalized lambda captures (init-capture) > <http://www.open-std.org/jtc1/sc22/wg21/...

...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: > > http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#submit_issue > It may be premature, but a resolution for the issue would be the same thing Boost does in this case: put the function in a subnamespace and introduce it to std via using declaration. I believe this should prevent it from being found via ADL. (Or does tha...

...f the C++11 standard [1] defines short/int/long/long long as signed. Bit-fields are discussed in 9.6 and have lots of implementation-defined behavior, but I don’t see anything about signedness. The ABI (e.g., [2]) defines whether char is signed or unsigned. [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3485.pdf [2]: http://www.cs.tufts.edu/comp/40/readings/amd64-abi.pdf

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++ standards in front of me but IIRC whether a > char/...

...from other developers here. Volatile isn’t specified in any decent normative way. There’s substantial documentation of intent, but C and C++ standards are lacking. We should therefore implement something that’s sensible and works kind-of as expected. I’ve documented specification and intent here: wg21.link/P1152R0 <http://wg21.link/P1152R0> If you want to follow-on (without all that documentation): wg21.link/P1152R1 <http://wg21.link/P1152R1> I think we want option 2.: keep volatile memcpy, and implement it as touching each byte exactly once. That’s unlikely to be particularly usefu...

...contentious [3]. empty() seems pretty innocuous though. Note that the standard proposals use std::range instead of std::iterator_range. In my opinion, other methods (e.g., front(), back(), and (for random access iterators) operator[]) would also be useful. [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1871.html [2]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html [3]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3513.html#range-arg

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 v). When using my...

As part of the work on C++17, WG21 released a series of "Technical Specifications", (TS) which added proposed new features to the standard library. These were all defined in the namespace 'std::experimental' (and namespaces inside of that). Then, much of these features were merged into the main standard, and becam...

...Line > Size. I wish to get this data from tblgen/TTI and I am happy to submit > patches on it. > > Yes, this sounds like the right direction. The targets obviously need to > provide this information. > I'd like to help review this as it'll be necessary to implement http://wg21.link/p0154r1 which is (likely) in C++17. It adds two values, constexpr std::hardware_{constructive,destructive}_interference_size, because in some configurations you don't have a precise cacheline size but rather a range based on what multiple architectures have implemented for the same ISA. I...

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 v). When using my...