<feed xmlns='http://www.w3.org/2005/Atom'>
<title>bcm5719-llvm/libcxx/src/include, branch meklort-10.0.1</title>
<subtitle>Project Ortega BCM5719 LLVM</subtitle>
<id>https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1</id>
<link rel='self' href='https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/'/>
<updated>2019-05-01T16:47:30+00:00</updated>
<entry>
<title>[WebAssembly] WASI support for libcxx</title>
<updated>2019-05-01T16:47:30+00:00</updated>
<author>
<name>Dan Gohman</name>
<email>dan433584@gmail.com</email>
</author>
<published>2019-05-01T16:47:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=3efd6e37e4b794f38a9f9d2403e48b3f4f88e2ae'/>
<id>urn:sha1:3efd6e37e4b794f38a9f9d2403e48b3f4f88e2ae</id>
<content type='text'>
This adds explicit support for the WASI platform to libcxx.

WASI libc uses some components from musl, however it's not fully compatible
with musl, so we're planning to stop using _LIBCPP_HAS_MUSL_LIBC and
customize for WASI libc specifically.

Differential Revision: https://reviews.llvm.org/D61336

Reviewers: sbc100, ldionne
llvm-svn: 359703
</content>
</entry>
<entry>
<title>Update more file headers across all of the LLVM projects in the monorepo</title>
<updated>2019-01-19T10:56:40+00:00</updated>
<author>
<name>Chandler Carruth</name>
<email>chandlerc@gmail.com</email>
</author>
<published>2019-01-19T10:56:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=57b08b0944046a6a57ee9b7b479181f548a5b9b4'/>
<id>urn:sha1:57b08b0944046a6a57ee9b7b479181f548a5b9b4</id>
<content type='text'>
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351648
</content>
</entry>
<entry>
<title>[libc++] Use __int128_t to represent file_time_type.</title>
<updated>2018-07-25T20:51:49+00:00</updated>
<author>
<name>Eric Fiselier</name>
<email>eric@efcs.ca</email>
</author>
<published>2018-07-25T20:51:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=c55ac1055a419eeca16ec885ec2d18c3d4124726'/>
<id>urn:sha1:c55ac1055a419eeca16ec885ec2d18c3d4124726</id>
<content type='text'>
Summary:
The ``file_time_type`` time point is used to represent the write times for files.
Its job is to act as part of a C++ wrapper for less ideal system interfaces. The
underlying filesystem uses the ``timespec`` struct for the same purpose.

However, the initial implementation of ``file_time_type`` could not represent
either the range or resolution of ``timespec``, making it unsuitable. Fixing
this requires an implementation which uses more than 64 bits to store the
time point.

I primarily considered two solutions: Using ``__int128_t`` and using a
arithmetic emulation of ``timespec``. Each has its pros and cons, and both
come with more than one complication.

However, after a lot of consideration, I decided on using `__int128_t`. This patch implements that change.

Please see the [FileTimeType Design Document](http://libcxx.llvm.org/docs/DesignDocs/FileTimeType.html) for more information.

Reviewers: mclow.lists, ldionne, joerg, arthur.j.odwyer, EricWF

Reviewed By: EricWF

Subscribers: christof, K-ballo, cfe-commits, BillyONeal

Differential Revision: https://reviews.llvm.org/D49774

llvm-svn: 337960
</content>
</entry>
<entry>
<title>Configure ELAST for MinGW</title>
<updated>2018-06-28T20:16:45+00:00</updated>
<author>
<name>Pirama Arumuga Nainar</name>
<email>pirama@google.com</email>
</author>
<published>2018-06-28T20:16:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=c83bbf55d745d5ed40b9efa9b8bc974278189f6d'/>
<id>urn:sha1:c83bbf55d745d5ed40b9efa9b8bc974278189f6d</id>
<content type='text'>
Summary:
Use _LIBCPP_MSVCRT_LIKE while configuring ELAST, so MinGW gets the same
configuration as MSVC.

Reviewers: compnerd, srhines, danalbert, mstorsjo

Subscribers: christof, ldionne, cfe-commits

Differential Revision: https://reviews.llvm.org/D48731

llvm-svn: 335916
</content>
</entry>
<entry>
<title>[libcxx] Add WebAssembly support</title>
<updated>2017-12-16T18:59:50+00:00</updated>
<author>
<name>Sam Clegg</name>
<email>sbc@chromium.org</email>
</author>
<published>2017-12-16T18:59:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=5029d676f82782c36b2217a542286eb1773756d5'/>
<id>urn:sha1:5029d676f82782c36b2217a542286eb1773756d5</id>
<content type='text'>
It turns out that this is the only change required in libcxx
for it to compile with the new `wasm32-unknown-unknown-wasm`
target recently added to Clang.

Patch by Nicholas Wilson!

Differential Revision: https://reviews.llvm.org/D41073

llvm-svn: 320925
</content>
</entry>
<entry>
<title>[libc++] Replace __sync_* functions with __libcpp_atomic_* functions</title>
<updated>2017-09-19T23:18:03+00:00</updated>
<author>
<name>Weiming Zhao</name>
<email>weimingz@codeaurora.org</email>
</author>
<published>2017-09-19T23:18:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=fbfaec7089b8bfc1e3ef91dfbc50b4b7cf7a79e7'/>
<id>urn:sha1:fbfaec7089b8bfc1e3ef91dfbc50b4b7cf7a79e7</id>
<content type='text'>
Summary:
This patch replaces __sync_* with __libcpp_atomic_* and adds a wrapper
function for __atomic_exchange to support _LIBCPP_HAS_NO_THREADS.

Reviewers: EricWF, jroelofs, mclow.lists, compnerd

Reviewed By: EricWF, compnerd

Subscribers: compnerd, efriedma, cfe-commits, joerg, llvm-commits

Differential Revision: https://reviews.llvm.org/D35235

llvm-svn: 313694
</content>
</entry>
<entry>
<title>Remove &lt;__refstring&gt; header; Move it into source directory.</title>
<updated>2017-07-12T01:38:35+00:00</updated>
<author>
<name>Eric Fiselier</name>
<email>eric@efcs.ca</email>
</author>
<published>2017-07-12T01:38:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=e3e7c0fb37adc8e3bd92fe550ca444edc0b75a75'/>
<id>urn:sha1:e3e7c0fb37adc8e3bd92fe550ca444edc0b75a75</id>
<content type='text'>
The libc++ &lt;__refstring&gt; headers has no real reason why it should
be a public header that libc++ ships. The only reason it was in the include
directory was because libc++abi needed it to build the library.

However keeping &lt;__refstring&gt; a header had other problems, like requiring its
dependancies to also be in the headers. For that reason this patch
moves it into the source directory.

To work around libc++abi's need for this header a duplicated copy was added
to libc++abi in r307748. While duplicating the code is an unfortunate solution
it's the best solution that's currently possible.

In the future I would like to start a discussion on the mailing lists about
making libc++abi build as a sub-project of libc++, requiring the libc++ sources
always be present.

llvm-svn: 307749
</content>
</entry>
<entry>
<title>Remove usages of _LIBCPP_MSVC which is never defined</title>
<updated>2017-05-10T21:40:58+00:00</updated>
<author>
<name>Eric Fiselier</name>
<email>eric@efcs.ca</email>
</author>
<published>2017-05-10T21:40:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=0c6e7ae4cc8039af611d7a5cf153d9bb7664f3e2'/>
<id>urn:sha1:0c6e7ae4cc8039af611d7a5cf153d9bb7664f3e2</id>
<content type='text'>
llvm-svn: 302736
</content>
</entry>
<entry>
<title>Refer to _LIBCPP_MSVC macro where applicable</title>
<updated>2017-02-06T05:26:49+00:00</updated>
<author>
<name>Saleem Abdulrasool</name>
<email>compnerd@compnerd.org</email>
</author>
<published>2017-02-06T05:26:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=bcc85cbcde661e8bf02a5e0c385f9aa509a8dc39'/>
<id>urn:sha1:bcc85cbcde661e8bf02a5e0c385f9aa509a8dc39</id>
<content type='text'>
Replace preprocess conditions of defined(_MSC_VER) &amp;&amp;
!defined(__clang__) with defined(_LIBCPP_MSVC).  NFC.

Patch by Dave Lee!

llvm-svn: 294171
</content>
</entry>
<entry>
<title>system_error: correct ELAST emulation on Windows</title>
<updated>2017-01-07T05:13:32+00:00</updated>
<author>
<name>Saleem Abdulrasool</name>
<email>compnerd@compnerd.org</email>
</author>
<published>2017-01-07T05:13:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/bcm5719-llvm/commit/?id=49a10e1c07bdda958fee7ddc9333e50cb8d08507'/>
<id>urn:sha1:49a10e1c07bdda958fee7ddc9333e50cb8d08507</id>
<content type='text'>
ELAST should point to the last valid error string value.  However,
`_sys_nerr` provides the number of elements in the errlist array.  Since
the index is 0-based, this is off-by-one.  Adjust it accordingly.

Thanks to David Majnemer for catching this!

llvm-svn: 291336
</content>
</entry>
</feed>
