This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
In 5d796645, we stopped looking at the LIBCXXABI_LIBCXX_INCLUDES variable,
which broke users of the Standalone build. This patch reinstates that
variable, however it must point to the *installed* path of the libc++
headers, not the libc++ headers in the source tree (which has always
been the case, but wasn't enforced before).
If LIBCXXABI_LIBCXX_INCLUDES points to the libc++ headers in the source
tree, the `__config_site` header will fail to be found.
Copy over the compiler detection structure from libcxx, and set
_LIBCXXABI_WEAK like _LIBCPP_WEAK is set in libcxx.
This allows users to override operator new/delete, if using those
operators from libcxxabi instead of from libcxx.
Differential Revision: https://reviews.llvm.org/D89863
This commit should really be named "Workaround external projects depending
on libc++ build system implementation details". It seems that the compiler-rt
build (and perhaps other projects) is relying on the fact that we copy libc++
and libc++abi headers to `<build-root>/include/c++/v1`. This was changed
by 5d796645, which moved the headers to `<build-root>/projects/libcxx/include/c++/v1`
and broke the compiler-rt build.
I'm committing this workaround to fix the compiler-rt build, but we should
remove reliance on implementation details like that. The correct way to
setup the compiler-rt build would be to "link" against the `cxx-headers`
target in CMake, or to run `install-cxx-headers` using an appropriate
installation prefix, and then manually add a `-I` path to that location.
While running this test on a bare metal target, I got an error as 'sleep' was not available on that system. As 'sleep' call is not doing anything useful for cases when _LIBCXXABI_HAS_NO_THREADS is defined. This patch puts it under this check.
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D89871
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D89041
This patch ensures that __shared_weak_count provides a consistent vtable
regardless of if RTTI is enabled or if we are targeting a static or shared
libc++ build.
This patch is technically ABI breaking, but only for a very specific
configuration that no vendor should be shipping.
Note that _LIBCPP_BUILD_STATIC is not normally defined when building
libc++.a, but instead it must be manually provided by the user or the
__config_site.
Differential Revision: https://reviews.llvm.org/D32838
Previously, we would define new/delete in both libc++ and libc++abi.
Not only does this cause code bloat, but also it's technically an ODR
violation since we don't know which operator will be selected. Furthermore,
since those are weak definitions, we should strive to have as few of them
as possible (to improve load times).
My preferred choice would have been to put the operators in libc++ only
by default, however that would create a circular dependency between
libc++ and libc++abi, which GNU linkers don't handle.
Folks who want to ship new/delete in libc++ instead of libc++abi are
free to do so by turning on LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS at
CMake configure time.
On Apple platforms, this shouldn't be an ABI break because we re-export
the new/delete symbols from libc++abi. This change actually makes libc++
behave closer to the system libc++ shipped on Apple platforms.
On other platforms, this is an ABI break for people linking against libc++
but not libc++abi. However, vendors have been consulted in D68269 and no
objection was raised. Furthermore, the definitions can be controlled to
appear in libc++ instead with the CMake option.
Differential Revision: https://reviews.llvm.org/D68269
This is the libcxxabi counterpart of D89545, and would have been part
of that patch if I'd spotted it soon enough (oops). One test in
libcxxabi is using the `%lu` printf format to refer to `size_t`, which
should be `%zu`.
Reviewed By: ldionne, #libc_abi
Differential Revision: https://reviews.llvm.org/D89547
Remove check for standalone and shared library mode in libcxxabi to
allow including tests in said mode. This check prevented running the
tests in standalone mode with static libraries, which is the case for
baremetal targets.
Fix check-unwind target trying to use a non-existent llvm-lit executable
in standalone mode. Copy the HandleOutOfTreeLLVM logic from libcxxabi to
libunwind in order to make the tests work in standalone mode.
Reviewed By: ldionne, #libc_abi, #libc
Differential Revision: https://reviews.llvm.org/D86540
We used <iostream> in several places where we don't actually need the
full power of <iostream>, and where using basic `std::printf` is enough.
This is better, since `std::printf` can be supported on systems that don't
have a notion of locales, while <iostream> can't.
There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).
This just adds the alternative spelling before the`-stdlib=` variant in all
these places
Reviewed By: ldionne
Differential Revision: https://reviews.llvm.org/D87133
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.
One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
This reverts commit c7d4aa711a. I am still investigating the issue,
but it looks like that commit has an interaction with ld64 that causes
new/delete weak re-exports not to work properly anymore. This is weird
because this commit did not touch the exports of new/delete -- I am
still investigating.
This is a temporary workaround until the new/delete situation is made
better (i.e. we don't include new/delete in both libc++ and libc++abi
by default).
Instead of managing two copies of the symbol lists, reuse the same list
in libc++abi and libc++.
Differential Revision: https://reviews.llvm.org/D88623
Setting _LIBCPP_HAS_NO_THREADS is needed when building libcxxabi without
threads in standalone mode. This is useful when target WASM. Otherwise,
you get an error like "No thread API" when building libcxxabi.
It would be better to link against a properly-configured libc++ headers
CMake target when building libc++abi instead, but we don't generate such
targets yet.
Thanks to Matthew Bauer for the patch.
Differential Revision: https://reviews.llvm.org/D60743
The needs of back-deployment testing currently require two different
ways of running the test suite: one based on the deployment target,
and one based on the target triple. Since the triple includes all the
information we need, it's better to have just one way of doing things.
Furthermore, `--param platform=XXX` is also supersedded by using the
target triple. Previously, this parameter would serve the purpose of
controling XFAILs for availability markup errors, however it is possible
to achieve the same thing by using with_system_cxx_lib only and using
.verify.cpp tests instead, as explained in the documentation changes.
The motivation for this change is twofold:
1. This part of the Lit config has always been really confusing and
complicated, and it has been a source of bugs in the past. I have
simplified it iteratively in the past, but the complexity is still
there.
2. The deployment-target detection started failing in weird ways in
recent Clangs, breaking our CI. Instead of band-aid patching the
issue, I decided to remove the complexity altogether by using target
triples even on Apple platforms.
A follow-up to this commit will bring the test suite in line with
the recommended way of handling availability markup tests.
Summary:
Caught by HWASAN on arm64 Android (which uses ld128 for long double). This
was running the existing fuzzer.
The specific minimized fuzz input to reproduce this is:
__cxa_demangle("1\006ILeeeEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE", 0, 0, 0);
Reviewers: eugenis, srhines, #libc_abi!
Subscribers: kristof.beyls, danielkiss, libcxx-commits
Tags: #libc_abi
Differential Revision: https://reviews.llvm.org/D77924
_cxa_guard_acquire is used for only one purpose,
namely guarding local static variable initialization,
and since that purpose is definitionally cold,
it should be attributed as cold
Reviewed By: ldionne
Reviewers: mclow.lists, ldionne, jfb, yfeldblum
Differential Revision: https://reviews.llvm.org/D85873
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
We want to be sure that atomic<size_t> is always lock-free, or the code
will be much slower than expected (and could even conceivably fail if
the lock implementation somehow calls back into libc++abi).
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
This patch adds Clang's new (and GCC's old) -Wsuggest-override to the warning flags for the LLVM build. The warning is a stronger form of -Winconsistent-missing-override which warns _everywhere_ that override is missing, not just in places where it's inconsistent within a class.
Some directories in the monorepo need the warning disabled for compatibility's, or sanity's, sake; in particular, libcxx/libcxxabi, and any code implementing or interoperating with googletest, googlemock, or google benchmark (which do not themselves use override). This patch adds -Wno-suggest-override to the relevant CMakeLists.txt's to accomplish this.
Differential Revision: https://reviews.llvm.org/D84126
sync_source_lists_from_cmake now also looks for source files in
`sources += [ "foo.cc" ]` lines, which allows us to remove most
`# Make `gn format` not collapse this` comments.
(sync_source_lists_from_cmake doesn't look for `foo_headers += [...]`
still, so the comment is still needed in two places for that.)
No intentional behavior change.
This test has been failing on some SDKs for a long time because we lack
a proper way of identifying the SDK version in Lit. Until that is possible,
mark the test as unsupported on Apple to restore the CI.
This allows passing parameters to the test suites without using
LLVM_LIT_ARGS. The problem is that we sometimes want to set some
Lit arguments on the CMake command line, but the Lit parameters in
a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS,
the command-line entry overrides the cache one, and the parameters
set by the cache are ignored.
This fixes a current issue with the build bots that they completely
ignore the 'std' param set by Lit, because other Lit arguments are
provided via LLVM_LIT_ARGS on the CMake command-line.
Instead of detecting it automatically (in libc++) and relying on
_LIBCXXABI_NO_EXCEPTIONS being set explicitly (in libc++abi), always
detect whether exceptions are enabled automatically.
This commit also removes support for specifying -D_LIBCPP_NO_EXCEPTIONS
and -D_LIBCXXABI_NO_EXCEPTIONS explicitly -- those should just be inferred
from using -fno-exceptions (or an equivalent flag).
Allowing both -D_FOO_NO_EXCEPTIONS to be provided explicitly and trying
to detect it automatically is just confusing, especially since we did
specify it explicitly when building libc++abi. We should have only one
way to detect whether exceptions are enabled, but it should be robust.
I ran into an error while trying to build libc++abi for a platform that
doesn't have <sys/types.h>. I couldn't find what <sys/types.h> was used
for in the header, so I think it's fine to remove it.
Differential Revision: https://reviews.llvm.org/D82810
As announced on libcxx-dev at [1], the old libc++ testing format is being
removed in favour of the new one. Follow-up commits will clean up the
code that is dead after the removal of this option.
[1]: http://lists.llvm.org/pipermail/libcxx-dev/2020-June/000885.html
This is necessary for standalone builds where the libc++ in use has a
custom configuration set up inside __config_site -- one needs to build
libc++abi against the installed headers of libc++ (which are properly
configured) instead of the ones inside libcxx/include.
See https://reviews.llvm.org/rGe619e9d#927848 for details.
The integration between CMake and executor selection in the new format
wasn't very flexible -- only the default executor and SSH executors were
supported.
This patch makes it possible to specify arbitrary executors with the new
format. With the new testing format, a custom executor is just a script
that gets called with a command-line to execute, and some arguments like
--env, --codesign_identity and --execdir. As such, the default executor
is just run.py.
Remote execution with the SSH executor can be achived by specifying
LIBCXX_EXECUTOR="<path-to-ssh.py> --host <host>". Similarly, arbitrary
scripts can be provided.
Since we have the monorepo, libc++abi's build requires a sibling checkout
of the libc++ sources. Hence, the logic for finding libc++ can be greatly
simplified.
Instead of passing file dependencies individually, assume that the
whole content of the unique test directory is a dependency. This
simplifies the test harness significantly, by making %T the directory
that contains everything required to run a test. This also removes the
need for the %{file_dependencies} substitution, which is removed by this
patch.
Furthermore, this patch also changes the harness to execute tests locally
inside %T, so as to avoid creating a separate directory for no purpose.
This clarifies the difference between test for exception support in
libc++abi tests and support for exceptions built into libc++abi.
This also removes the rather confusing similarity between the
_LIBCXXABI_NO_EXCEPTIONS and LIBCXXABI_HAS_NO_EXCEPTIONS macros.
Finally, TEST_HAS_NO_EXCEPTIONS is also detected automatically based
on -fno-exceptions, so it doesn't have to be specified explicitly
through Lit's compile_flags.
0e04342ae0 simplified exceptions-related configurations for libc++abi
and libunwind by reusing the logic in libc++. However, it missed the fact
that libc++abi and libunwind were overriding libc++'s handling of exceptions.
This commit removes special handling in libc++abi and libunwind to use
the logic in libc++, which is the right one.
First, libc++abi doesn't need to add the no-exceptions Lit feature itself,
since that is already done in the config.py for libc++, which it reuses.
Specifically, config.enable_exceptions is set based on @LIBCXXABI_ENABLE_EXCEPTIONS@
in libc++abi's lit.cfg.in, and libc++'s config.py handles that correctly.
Secondly, libunwind's LIBUNWIND_ENABLE_EXCEPTIONS is never set (it's
probably a remnant of copy-pasting code between the runtime libraries),
so the library is always built with exceptions disabled (which makes
sense since it implements the runtime support for exceptions).
Conversely, the test suite is always run with exceptions enabled
(not sure why), but that is preserved by the default behavior of
libc++'s config.py.
Since <unwind.h> is in the SDK, not in /usr/include, the XFAILs must
be predicated on the compiler version (ideally even on the SDK version)
instead of the target system version.
C++98 and C++03 are effectively aliases as far as Clang is concerned.
As such, allowing both std=c++98 and std=c++03 as Lit parameters is
just slightly confusing, but provides no value. It's similar to allowing
both std=c++17 and std=c++1z, which we don't do.
This was discovered because we had an internal bot that ran the test
suite under both c++98 AND c++03 -- one of which is redundant.
Differential Revision: https://reviews.llvm.org/D80926
When building the system libc++abi for Apple, we use CrashReporterClient
to provide better crash logs when calling abort(). This is exemplified by
the fact that we test for the presence of <CrashReporterClient.h> in
abort_message.cpp.
However, we must link against CrashReporterClient.a in order to get that
functionality, otherwise we get a linking error.
Slightly older Clangs seem to think they are more clever than they really
are, and they think the code can never be executed. The code can actually
be executed in case the exception runtime is mis-implemented, which is
exactly what this test is testing. This commit just disables the spurious
warning.
Android doesn't have a libgcc_s and uses libgcc instead, so adjust the
build accordingly. This matches compiler-rt's build setup. libc++abi and
libunwind were already checking for libgcc but in a different context.
This change makes them search only for libgcc on Android now, but the
code to link against libgcc if it were present was already there.
Reviewed By: #libc, #libc_abi, #libunwind, rprichard, srhines
Differential Revision: https://reviews.llvm.org/D78787
Instead of the ad-hoc #define _LIBCXX_DYNAMIC_FALLBACK, provide an option
to enable the setting when building libc++abi. Also use the occasion to
rename the option to something slightly more descriptive.
Note that in the future, it would be great to simply remove this option
altogether. However, in the meantime, it seems better to have it be an
official option than something ad-hoc.
Instead of having different names for the same Lit feature accross code
bases, use the same name everywhere. This NFC commit is in preparation
for a refactor where all three projects will be using the same Lit
feature detection logic, and hence it won't be convenient to use
different names for the feature.
Differential Revision: https://reviews.llvm.org/D78370
This upstreams a fix that Howard made a long time ago, where so many
errors would be logged that applications were becoming sluggish. With
this patch, the first three errors will be printed, and after that the
printing frequency decreases exponentially.
_LIBCXX_DYNAMIC_FALLBACK is only enabled on Apple platforms, so this
should be NFC for other platforms.
rdar://14996273
Differential Revision: https://reviews.llvm.org/D78330
We previously tried re-exporting symbols that didn't exist when
exceptions were disabled. Note that building libc++abi without
exceptions still doesn't work when linking against the default-provided
libSystem.dylib, because it transitively depends on libobjc.dylib,
and that requires __gxx_personality_v0. But building libc++abi
with exceptions and libc++ without exceptions does work.
Summary:
This patch is to fix the parsing of long double literals encoded with the e prefix on PowerPC and S390. For both PowerPC and S390, type code e is used for 64-bit long double literals and g is used for 128-bit long double literals. libcxxabi test case test_demangle.pass.cpp fails without the fix.
Authored by: xingxue-ibm
Reviewers: hubert.reinterpretcast, jasonliu, erik.pilkington, uweigand, mclow.li
sts, libc++abi
Reviewed by: hubert.reinterpretcast, erik.pilkington
Differential Revision: https://reviews.llvm.org/D74163
The new format should be equivalent to the old format, and it is now the
default format when running the libc++ tests. This commit changes the
libc++abi tests to use the new format by default too. If unexpected failures
are discovered, it should be fine to revert this commit until they are
addressed.
Also note that it is still possible to use the old format by passing
`--param=use_old_format=True` when running Lit for the time being.
The LitConfig is shared across the whole test suite. However, since
enabling recursive expansion can be a breaking change for some test
suites, it's important to confine the setting to test suites that
enable it explicitly.
Note that other issues were raised with the way recursiveExpansionLimit
operates. However, this commit simply moves the setting to the right
place -- the mechanism by which it works can be improved independently.
Differential Revision: https://reviews.llvm.org/D77415
This new test format is simpler and more flexible. It creates Lit ShTests
on the fly that reuse existing substitutions (like %{cxx}) instead of
having complex logic in Python to run the tests. This has the benefit
that virtually no coding is required to customize how the test suite is
run -- one can achieve pretty much anything by defining the appropriate
substitutions in a simple lit.cfg file.
For example, in order to run the tests on an embedded device after
building with a specific SDK, one can set the %{cxx} and %{compile_flags}
substitutions to use that SDK, and the %{exec} substitution to the ssh.py
script currently used for .sh.cpp tests with a remote executor. Dealing with
the SSHExecutor becomes unnecessary, since all tests are treated like ShTests.
As a side effect of this design, configuration files for the test
suite can be as simple as:
config.substitutions.append(('%{cxx}', '<path-to-compiler>'))
config.substitutions.append(('%{compile_flags}', '<flags>'))
config.substitutions.append(('%{link_flags}', '<flags>'))
config.substitutions.append(('%{exec}', '<script-to-execute>'))
This should allow storing lit.cfg files for various configurations
directly in the repository instead of relying on complicated logic
in config.py to set up the right flags. I've found numerous problems
in that logic in the past years, and it seems like having simple and
explicit configuration files for the configurations we support is
going to solve most of these problems. Specifically, I am hoping to
store configuration files for testing other Standard Libraries in
the repository.
Improving the interaction with the test suite configuration is still a
work in progress, so for now this test format reuses the substitutions and
available features that are set up by the current config.py.
This new test format should support pretty much everything that the current
test format supports, however it will not be enabled by default at first to
make sure we're satisfied with it. For a short period of time, the new format
will require `--param=use_new_format=True` to be enabled, however it is a very
short term goal to replace the current testing format entirely and to simplify
the configuration accordingly.
Differential Revision: https://reviews.llvm.org/D77338
To avoid wasting the valuable time of contributors, add a link to a
blocked review to document additional issues with the removal of some
GCC 4.9 workaround.
We will soon start removing technical debt and sharing code between the
two directories, so this first step is meant to discover potential places
where the libraries are built outside of a monorepo layout. I imagine
this could happen as a remnant of the pre-monorepo setup.
This was discussed on the libcxx-dev mailing list and we got overall
consensus on the direction. All consumers of libc++ and libc++abi
should already be doing so through the monorepo, however it is
possible that we catch some stragglers with this patch, in which
case it may need to be reverted temporarily.
Differential Revision: https://reviews.llvm.org/D76102
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
This is a re-application of f383fb40b1, wich was reverted in 04d48111b
because the build bots had not been updated yet. The build bot configurations
have now been updated not to use the deprecated targets, and I verified
that they were using the non-deprecated targets, so we should be good
unless I missed a bot.
Differential Revision: https://reviews.llvm.org/D76104
lit is not very clever when it performs substitution on RUN lines. It
simply looks for a match anywhere in the line (without tokenization)
and replaces it by the expansion. This means that a RUN line containing
e.g. `-verify-ignore-unexpected=note` wouod be expanded to
`-verify-ignore-unexpected=<substitution for not>e`, which is
surprising and nonsensical.
It also means that something like `%compile_module` could be expanded
to `<substitution-for-%compile>_module` or to the correct substitution,
depending on the order in which substitutions are evaluated by lit.
To avoid such problems, it is a good habit to delimit custom substitutions
with some token. This commit does that for all substitutions used in the
libc++ and libc++abi test suites.
This reverts commit f383fb40b. It looks like several of our build bots
are still using the legacy target names, so we'll change those before
we commit this change again.
We've been meaning to remove those targets for a while, and the fix is
simple enough cause they're all just aliases to other targets.
There's no doubt this commit will break some CI systems, however the
fix is trivial.
Differential Revision: https://reviews.llvm.org/D76104
Since the atomic_support.h header of libc++abi is considered technical
debt (since we should use libc++'s), it's better not to add new
definitions to it, which makes it diverge from the original libc++
header even more.
Differential Revision: https://reviews.llvm.org/D75950
It seems to me that abort_message.h is always included in a C++ file, so
it's fine to assume that it's C++ code.
Differential Revision: https://reviews.llvm.org/D76027
Summary:
The return type of __cxa_finalize is documented as void in the Itanium
C++ ABI, and it is void in various C libraries.
Reviewers: EricWF, ldionne, compnerd, mclow.lists, MaskRay
Reviewed By: MaskRay
Subscribers: MaskRay, dexonsmith, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D75795
Win64 isn't LP64, it's LLP64, but there's no __LLP64__ predefined -
just check _WIN64 in addition to __LP64__.
This fixes compilation after static asserts about the struct layout
were added in f2a436058f.
Differential Revision: https://reviews.llvm.org/D73838
Louis Dionne