search for: jtc1

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 inco...

...pping older 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.htm...

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 ti...

...wrote: > >> 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...

...> > "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/j...

...> 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/...

...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 > 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. (O...

...on 3.9.1 of 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++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/...

...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/...

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

...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/sc...

...somewhat 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). Whe...

...t;>>> 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) >&...

...t some particular point? >> See **** DETAILS **** for in depth (I hope enough!) study/report. >>> >>> Aki >> >> I would guess this is not "c99" way... > > It seems to fail on a C99 feature called Compound Literal (see > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf, Section > 6.5.2.5). > > It should be supported by AIX: > > https://www.ibm.com/support/knowledgecenter/SSGH3R_13.1.3/com.ibm.xlcpp1313.aix.doc/language_ref/compound_literals.html > > > I have no idea why it would fail here. > > Regards,...

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). Whe...

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

...Orc/CompileOnDemandLayer.h:314:29: > warning: redundant move in return statement [-Wredundant-move] > 314 |         return std::move(Err); Note that the move (into the implicit JITSymbol(Error) ctor) is only redundant if the compiler implements a fix for <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> "Return by converting move constructor". (But not sure whether the LLVM compiler baselines imply that, anyway. In LibreOffice it forced me to introduce ugly #ifs, to not have to disable that warning outright, <https://cgit.freedesktop.org/...

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, November 06, 2013 6:28 PM To: Yin Ma; 'llvmdev Dev' Subject: Re: [LLVMdev] Should remove calling NULL pointer or not O...