Displaying 20 results from an estimated 26 matches for "isocpp".
Did you mean:
isoc
2016 Feb 20
3
[isocpp-parallel] Proposal for new memory_order_consume definition
...nsics for comparisons
that avoid breaking dependencies enables the annotation to remain
optional.
Thanx, Paul
> Sent from my BlackBerry portable Babbage Device
> Original Message
> From: Paul E. McKenney
> Sent: Thursday, February 18, 2016 4:58 AM
> To: parallel at lists.isocpp.org; linux-kernel at vger.kernel.org; linux-arch at vger.kernel.org; gcc at gcc.gnu.org; llvm-dev at lists.llvm.org
> Reply To: parallel at lists.isocpp.org
> Cc: peterz at infradead.org; j.alglave at ucl.ac.uk; will.deacon at arm.com; dhowells at redhat.com; Ramana.Radhakrishnan at arm.com;...
2016 Feb 26
0
[isocpp-parallel] Proposal for new memory_order_consume definition
...t; optional.
>
> Thanx, Paul
>
> > Sent from my BlackBerry portable Babbage Device
> > Original Message
> > From: Paul E. McKenney
> > Sent: Thursday, February 18, 2016 4:58 AM
> > To: parallel at lists.isocpp.org; linux-kernel at vger.kernel.org;
> linux-arch at vger.kernel.org; gcc at gcc.gnu.org; llvm-dev at lists.llvm.org
> > Reply To: parallel at lists.isocpp.org
> > Cc: peterz at infradead.org; j.alglave at ucl.ac.uk; will.deacon at arm.com;
> dhowells at redhat.com; Ramana.Radhak...
2016 Feb 18
2
Proposal for new memory_order_consume definition
Hello!
A proposal (quaintly identified as P0190R0) for a new memory_order_consume
definition may be found here:
http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf
As requested at the October C++ Standards Committee meeting, this
is a follow-on to P0098R1 that picks one alternative and describes
it in detail. This approach focuses on existing practice, with the
goal of
2016 Feb 27
4
[isocpp-parallel] Proposal for new memory_order_consume definition
...Thanx, Paul
> >
> > > Sent from my BlackBerry portable Babbage Device
> > > Original Message
> > > From: Paul E. McKenney
> > > Sent: Thursday, February 18, 2016 4:58 AM
> > > To: parallel at lists.isocpp.org; linux-kernel at vger.kernel.org;
> > linux-arch at vger.kernel.org; gcc at gcc.gnu.org; llvm-dev at lists.llvm.org
> > > Reply To: parallel at lists.isocpp.org
> > > Cc: peterz at infradead.org; j.alglave at ucl.ac.uk; will.deacon at arm.com;
> > dhowells at redha...
2012 Oct 15
1
[BUG] Lucene plugin breaks header substring search
According to the IMAP spec if I do a search for "TO isocpp.org" it
should find all the messages whose To: field contains the string
"isocpp.org", but dovecot is returning me an empty list. However, a
search for "TO tm at isocpp.org" produces a long list of messages. This
behavior is present if I *even load* the lucene fts plugin....
2016 Feb 27
0
[isocpp-parallel] Proposal for new memory_order_consume definition
On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at linux.vnet.ibm.com>
wrote:
>
>
> But we do already have something very similar with signed integer
> overflow. If the compiler can see a way to generate faster code that
> does not handle the overflow case, then the semantics suddenly change
> from twos-complement arithmetic to something very strange. The
2016 Feb 28
0
[isocpp-parallel] Proposal for new memory_order_consume definition
On 2016.02.27 at 15:10 -0800, Paul E. McKenney via llvm-dev wrote:
> On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote:
> > On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at linux.vnet.ibm.com>
> > wrote:
> > >
> > >
> > > But we do already have something very similar with signed integer
> > > overflow. If the
2016 Feb 29
0
[isocpp-parallel] Proposal for new memory_order_consume definition
Hi,
On Sun, 28 Feb 2016, Linus Torvalds wrote:
> > So the kernel obviously is already using its own C dialect, that is
> > pretty far from standard C. All these options also have a negative
> > impact on the performance of the generated code.
>
> They really don't.
They do.
> Have you ever seen code that cared about signed integer overflow?
>
> Yeah,
2016 Feb 29
0
[isocpp-parallel] Proposal for new memory_order_consume definition
On 2/28/16, Linus Torvalds <torvalds at linux-foundation.org> wrote:
> The fact is, undefined compiler behavior is never a good idea. Not for
> serious projects.
Actually, undefined behavior is essential for serious projects, but
not for the reasons mentioned.
If the language has no undefined behavior, then from the compiler's view,
there is no such thing as a bad program. All
2016 Feb 27
2
[isocpp-parallel] Proposal for new memory_order_consume definition
On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote:
> On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at linux.vnet.ibm.com>
> wrote:
> >
> >
> > But we do already have something very similar with signed integer
> > overflow. If the compiler can see a way to generate faster code that
> > does not handle the overflow case, then the
2016 Feb 29
0
[isocpp-parallel] Proposal for new memory_order_consume definition
Hi,
On Sat, 27 Feb 2016, Paul E. McKenney wrote:
> But we do already have something very similar with signed integer
> overflow. If the compiler can see a way to generate faster code that
> does not handle the overflow case, then the semantics suddenly change
> from twos-complement arithmetic to something very strange. The standard
> does not specify all the ways that the
2016 Feb 28
7
[isocpp-parallel] Proposal for new memory_order_consume definition
On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf
<markus at trippelsdorf.de> wrote:
>> >
>> > -fno-strict-overflow
>>
>> -fno-strict-aliasing.
>
> Do not forget -fno-delete-null-pointer-checks.
>
> So the kernel obviously is already using its own C dialect, that is
> pretty far from standard C.
> All these options also have a negative
2015 Sep 28
2
How to unscribe from all the emails
...ved manually by a moderator.
> Also you’ll receive answer to your questions as long as people use
> “reply-all”.
>
> You can’t (AFAIK) just subscribe to individual threads.
>
> Best,
>
> —
> Mehdi
>
That's strange. i'm subscribed to C++ FAQ (faq-discussion at isocpp.org,
which I've subscribed to through google groups) and I don't get a lot of
unrelated emails.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150928/5a25ee94/attachment.html>
2013 Oct 06
1
R 3.1.0 and C++11
...required. People do try to use R internals in C++, but C++98
compilers are not required to support these types (and there are
currently no C++11 compilers).
But since the summer we have g++ and clang with working C++11 implementations:
iii) g++ implements C++11:
http://isocpp.org/blog/2013/05/gcc-4.8.1-released-c11-feature-complete
iv) llvm/clang++ implements C++11:
http://isocpp.org/blog/2013/06/llvm-3.3-is-released
I would suggest to change the wording prior to the release of R 3.1.0 next
year as it is likely that even Microsoft will by then have a fully-...
2019 Jun 08
4
[RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
..., Garbage Out: Arguing about Undefined Behavior...](
https://www.youtube.com/watch?v=yG1OZ69H_-o), as well as this panel
discussion:
- https://www.youtube.com/watch?v=Puio5dly9N8#t=12m12s
- https://www.youtube.com/watch?v=Puio5dly9N8#t=42m40s
Other coding guidelines already embrace this:
- http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-signed
- http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-unsigned
- https://google.github.io/styleguide/cppguide.html#Integer_Types
It is rare that overflowing (and wrapping) an unsigned integer won't
trigger a program bug when...
2020 Feb 11
1
Minor typo in recent commit
...R-exts.texi
+++ b/doc/manual/R-exts.texi
@@ -2631,9 +2631,9 @@ not necessarily installed) on all known @R{}
platforms. As from @R{}
4.0.0 a C++ compiler will be selected only if it conforms to the 2011
standard (`C++11'). A minor update at footnote{The changes are linked from
@uref{https://isocpp.org/@/std/@/standing-documents/@/sd-6-sg10-feature-test-recommendations}.}
-(`C++14') was published in December 2014. The latest standard (`C++17')
-was published in December 2017, and a further revision (`C++20') is in
-preparation.
+(`C++14') was published in December 2014. A r...
2020 Mar 10
2
GSoC: Improve parallelism-aware analyses and optimizations
...ms(hardware
concepts)*
(ex.TMP, constexpr, RAII, RVO, cache lines, move semantics, undefined
behaviors, thread-safety, etc.)
*Which I came to know about, by closely following C++ communities and
events such as cpplang.slack.com <http://cpplang.slack.com/>, CPPcon, core
guidelines <https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines>.*
Although, I have already started going through the code base and will soon
push some bug fixes.
Can you please suggest how to proceed with this project.
Thanks and Regards,
Abhay
-------------- next part --------------
An HTML attachment was sc...
2015 Apr 10
4
[LLVMdev] Optimization on Atomics (and the OpenMP memory model)
Hi everyone,
The OpenMP standards committee has begun work to formalize their memory model, and define its relationship to the C/C++ memory models. A questionnaire has been put together (pasted below), and I'd like everyone's help in composing detailed answers to inform their decision-making process. While our OpenMP support is still in active development, many of these questions apply
2015 Feb 09
2
[LLVMdev] Any mechanism available for link time inlineing?
Hi,
trying to develop this idea of splitting c++ classes into real interface
and implementation and to make a std isocpp proposal out of it. Need some
help and info to make the proposal cover as many details as possible.
The idea is to split the class declaration into a part that will stay in
the header and will contain only the public members. (let's ignore
protected for the moment). The c++ part will contain t...
2015 Sep 27
4
How to unscribe from all the emails
I keep getting a ton of emails from llvm-dev. None of them are related to
my original post. Is it possible to unscribe from all of these emails?
--
Rail Shafigulin
Software Engineer
Esencia Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150926/e3d83b40/attachment.html>