replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Bruce Mitchener: Minor typo fixes. 

llvm-svn: 175274
This commit is contained in:
Howard Hinnant 2013-02-15 15:37:50 +00:00
parent 1fd843eee7
commit 65af0388b9
3 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
libcxx/www/atomic_design.html
View File

@ -37,7 +37,7 @@
<p>
There are currently 3 designs under consideration. They differ in where most
of the implmentation work is done. The functionality exposed to the customer
of the implementation work is done. The functionality exposed to the customer
should be identical (and conforming) for all three designs.
</p>

4
libcxx/www/atomic_design_a.html
View File

@ -38,7 +38,7 @@
<p>
The compiler supplies all of the intrinsics as described below. This list of
intrinsics roughly parallels the requirements of the C and C++ atomics
proposals. The C and C++ library imlpementations simply drop through to these
proposals. The C and C++ library implementations simply drop through to these
intrinsics. Anything the platform does not support in hardware, the compiler
arranges for a (compiler-rt) library call to be made which will do the job with
a mutex, and in this case ignoring the memory ordering parameter (effectively
@ -52,7 +52,7 @@ behavior is acceptable when the inputs do not conform as defined below.
<blockquote><pre>
<font color="#C80000">// In every intrinsic signature below, type* atomic_obj may be a pointer to a</font>
<font color="#C80000">// volatile-qualifed type.</font>
<font color="#C80000">// volatile-qualified type.</font>
<font color="#C80000">// Memory ordering values map to the following meanings:</font>
<font color="#C80000">// memory_order_relaxed == 0</font>
<font color="#C80000">// memory_order_consume == 1</font>

2
libcxx/www/atomic_design_c.html
View File

@ -43,7 +43,7 @@ inserted directly into your application ... assembly that is not otherwise
representable by higher level C or C++ expressions. The design of the libc++
<tt>&lt;atomic&gt;</tt> header started with this goal in mind. A secondary, but
still very important goal is that the compiler should have to do minimal work to
faciliate the implementaiton of <tt>&lt;atomic&gt;</tt>. Without this second
facilitate the implementation of <tt>&lt;atomic&gt;</tt>. Without this second
goal, then practically speaking, the libc++ <tt>&lt;atomic&gt;</tt> header would
be doomed to be a barely supported, second class citizen on almost every
platform.