[libc++] Re-apply "Always build c++experimental.a""

This re-applies bb939931a1ad, which had been reverted by 09cebfb978de
because it broke Chromium. The issues seen by Chromium should be
addressed b

[libc++] Re-apply "Always build c++experimental.a""

This re-applies bb939931a1ad, which had been reverted by 09cebfb978de
because it broke Chromium. The issues seen by Chromium should be
addressed by 1d0f79558ca4.

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

show more ...

Revert "[libc++] Always build c++experimental.a"

This caused build failures when building Clang and libc++ together on Mac:

fatal error: 'experimental/memory_resource' file not found

See the cod

Revert "[libc++] Always build c++experimental.a"

This caused build failures when building Clang and libc++ together on Mac:

fatal error: 'experimental/memory_resource' file not found

See the code review for details. Reverting until the problem and how to
solve it is better understood.

(Updates to some test files were not reverted, since they seemed
unrelated and were later updated by 340b48b267b96.)

> This is the first part of a plan to ship experimental features
> by default while guarding them behind a compiler flag to avoid
> users accidentally depending on them. Subsequent patches will
> also encompass incomplete features (such as <format> and <ranges>)
> in that categorization. Basically, the idea is that we always
> build and ship the c++experimental library, however users can't
> use what's in it unless they pass the `-funstable` flag to Clang.
>
> Note that this patch intentionally does not start guarding
> existing <experimental/FOO> content behind the flag, because
> that would merely break users that might be relying on such
> content being in the headers unconditionally. Instead, we
> should start guarding new TSes behind the flag, and get rid
> of the existing TSes we have by shipping their Standard
> counterpart.
>
> Also, this patch must jump through a few hoops like defining
> _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
> that do not implement -funstable yet.
>
> Differential Revision: https://reviews.llvm.org/D128927

This reverts commit bb939931a1adb9a47a2de13c359d6a72aeb277c8.

show more ...

[libc++] Always build c++experimental.a

This is the first part of a plan to ship experimental features
by default while guarding them behind a compiler flag to avoid
users accidentally depending on

[libc++] Always build c++experimental.a

This is the first part of a plan to ship experimental features
by default while guarding them behind a compiler flag to avoid
users accidentally depending on them. Subsequent patches will
also encompass incomplete features (such as <format> and <ranges>)
in that categorization. Basically, the idea is that we always
build and ship the c++experimental library, however users can't
use what's in it unless they pass the `-funstable` flag to Clang.

Note that this patch intentionally does not start guarding
existing <experimental/FOO> content behind the flag, because
that would merely break users that might be relying on such
content being in the headers unconditionally. Instead, we
should start guarding new TSes behind the flag, and get rid
of the existing TSes we have by shipping their Standard
counterpart.

Also, this patch must jump through a few hoops like defining
_LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
that do not implement -funstable yet.

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

show more ...

Revert "[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi"

This reverts commit 4164cfa537e545f8ea9bc4f3c8b913867a7ac79d since
it broke the clang-x86_64-debian-fast builder:

https://la

Revert "[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi"

This reverts commit 4164cfa537e545f8ea9bc4f3c8b913867a7ac79d since
it broke the clang-x86_64-debian-fast builder:

https://lab.llvm.org/buildbot/#/builders/109/builds/41339

show more ...

[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi

We no longer support the use of LLVM_ENABLE_PROJECTS for libcxx and
libcxxabi. We don't use paths to libcxx and libcxxabi in compiler-rt

[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi

We no longer support the use of LLVM_ENABLE_PROJECTS for libcxx and
libcxxabi. We don't use paths to libcxx and libcxxabi in compiler-rt.

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

show more ...

Revert "[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi"

This reverts commit c0d4f2282d8335cd15338663b18cd7f22155456e which
broke clang-x86_64-debian-fast:

https://lab.llvm.org/buil

Revert "[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi"

This reverts commit c0d4f2282d8335cd15338663b18cd7f22155456e which
broke clang-x86_64-debian-fast:

https://lab.llvm.org/buildbot/#/builders/109/builds/41268

show more ...

[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi

We no longer support the use of LLVM_ENABLE_PROJECTS for libcxx and
libcxxabi. We don't use paths to libcxx and libcxxabi in compiler-rt

[CMake][compiler-rt] Clean up the use of libcxx and libcxxabi

We no longer support the use of LLVM_ENABLE_PROJECTS for libcxx and
libcxxabi. We don't use paths to libcxx and libcxxabi in compiler-rt.

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

show more ...

[CMake][compiler-rt] Use COMPILE_OPTIONS and LINK_OPTIONS

This avoids the need for string-ification and lets CMake deduplicate
potentially duplicate flags.

Differential Revision: https://reviews.ll

[CMake][compiler-rt] Use COMPILE_OPTIONS and LINK_OPTIONS

This avoids the need for string-ification and lets CMake deduplicate
potentially duplicate flags.

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

show more ...

Pass through even more LIBCXX_* variables to libfuzzer's custom lib++

Similar to D120946, pass LIBCXX_HAS_GCC_S_LIB and LIBCXX_USE_COMPILER_RT
through to the custom lib++ builds so that libfuzzer do

Pass through even more LIBCXX_* variables to libfuzzer's custom lib++

Similar to D120946, pass LIBCXX_HAS_GCC_S_LIB and LIBCXX_USE_COMPILER_RT
through to the custom lib++ builds so that libfuzzer doesn't end up with
a .deplibs section that links against those libraries when the
variables are set to false.

Reviewed By: phosek

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

show more ...

Revert "[compiler-rt] Use C_STANDARD instead of custom logic for adding -std=c11"

This reverts commit 2f251925db060f83894a4cf5448259b7a1255552.

This was reported to break the Builtins-powerpc64le-l

Revert "[compiler-rt] Use C_STANDARD instead of custom logic for adding -std=c11"

This reverts commit 2f251925db060f83894a4cf5448259b7a1255552.

This was reported to break the Builtins-powerpc64le-linux::qdiv_test.c
test on ppc64le buildbots, e.g. these:

https://lab.llvm.org/buildbot/#/builders/105/builds/24538
https://lab.llvm.org/buildbot/#/builders/121/builds/18755

show more ...

[compiler-rt] Use C_STANDARD instead of custom logic for adding -std=c11

Apply this in add_compiler_rt_runtime instead of manually adding it
to the individual projects. This applies the option on mo

[compiler-rt] Use C_STANDARD instead of custom logic for adding -std=c11

Apply this in add_compiler_rt_runtime instead of manually adding it
to the individual projects. This applies the option on more
parts of compiler-rt than before, but should ideally not make any
difference assuming the other runtimes that lacked the option
also were C11 compatible.

Not marking this as required, to match the existing behaviour (where
`-std=c11` was added only if supported by the compiler).

This was suggested during the review of D110005.

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

show more ...

[compiler-rt][sanitizers] build ubsan, asan etc libraries with Mac Catalyst support

Like D118875, but for ubsan, asan, etc.

With this, I can successfully run:

bin/clang++ -target x86_64-apple-

[compiler-rt][sanitizers] build ubsan, asan etc libraries with Mac Catalyst support

Like D118875, but for ubsan, asan, etc.

With this, I can successfully run:

bin/clang++ -target x86_64-apple-ios14.0-macabi foo.cc \
-isysroot $(xcrun -show-sdk-path) -fsanitize=undefined

with a locally built libclang_rt.ubsan_osx_dynamic.dylib.

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

show more ...

[compiler-rt] Don't explictly ad-hoc sign dylibs on APPLE if ld is new enough

ld64 implicitly ad-hoc code-signs as of Xcode 12, and `strip` and friends know
how keep this special ad-hoc signature va

[compiler-rt] Don't explictly ad-hoc sign dylibs on APPLE if ld is new enough

ld64 implicitly ad-hoc code-signs as of Xcode 12, and `strip` and friends know
how keep this special ad-hoc signature valid.

So this should have no effective behavior change, except that you can now strip
libclang_rt.asan_osx_dynamic.dylib and it'll still have a valid ad-hoc
signature, instead of strip printing "warning: changes being made to the file
will invalidate the code signature in:" and making the ad-hoc code signature
invalid.

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

show more ...

[CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.

Differential Revision: https://reviews.l

[CMake] Rename TARGET_TRIPLE to LLVM_TARGET_TRIPLE

This clarifies that this is an LLVM specific variable and avoids
potential conflicts with other projects.

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

show more ...

Pass through more LIBCXX_* variables to libfuzzer's custom lib++

Pass LIBCXX_HAS_PTHREAD_LIB, LIBCXX_HAS_RT_LIB and LIBCXXABI_HAS_PTHREAD_LIB
through to the custom lib++ builds so that libfuzzer

Pass through more LIBCXX_* variables to libfuzzer's custom lib++

Pass LIBCXX_HAS_PTHREAD_LIB, LIBCXX_HAS_RT_LIB and LIBCXXABI_HAS_PTHREAD_LIB
through to the custom lib++ builds so that libfuzzer doesn't end up with a .deplibs section that
links against those libraries when the variables are set to false.

Reviewed By: phosek

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

show more ...

[llvm-libgcc] initial commit

Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`,
and `libgcc_s.so`.

Enabling libunwind as a replacement for libgcc on Linux has proven to be
chal

[llvm-libgcc] initial commit

Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`,
and `libgcc_s.so`.

Enabling libunwind as a replacement for libgcc on Linux has proven to be
challenging since libgcc_s.so is a required dependency in the [Linux
standard base][5]. Some software is transitively dependent on libgcc
because glibc makes hardcoded calls to functions in libgcc_s. For example,
the function `__GI___backtrace` eventually makes its way to a [hardcoded
dlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} and
libunwind have the same ABI, but different implementations, the two
libraries end up [cross-talking, which ultimately results in a
segfault][2].

To solve this problem, libunwind needs to build a “libgcc”. That is, link
the necessary functions from compiler-rt and libunwind into an archive
and shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`,
and `libgcc_s.so`, so that glibc’s baked calls are diverted to the
correct objects in memory. Fortunately for us, compiler-rt and libunwind
use the same ABI as the libgcc family, so the problem is solvable at the
llvm-project configuration level: no program source needs to be edited.
Thus, the end result is for a user to configure their LLVM build with a
flag that indicates they want to archive compiler-rt/unwind as libgcc.
We achieve this by compiling libunwind with all the symbols necessary
for compiler-rt to emulate the libgcc family, and then generate symlinks
named for our "libgcc" that point to their corresponding libunwind
counterparts.

We alternatively considered patching glibc so that the source doesn't
directly refer to libgcc, but rather _defaults_ to libgcc, so that a
system preferring compiler-rt/libunwind can point to these libraries
at the config stage instead. Even if we modified the Linux standard
base, this alternative won't work because binaries that are built using
libgcc will still end up having crosstalk between the differing
implementations.

This problem has been solved in this manner for [FreeBSD][3], and this
CL has been tested against [Chrome OS][4].

[1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16
[3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s
[4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947
[5]: https://refspecs.linuxbase.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html

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

show more ...

[compiler-rt] Force ABI to libcxxabi when building cxustom libc++

Follow-up to 458ead66dc37, which replaced the bespoke CMakeLists.txt
file for building a custom instrumented libc++ with an invocati

[compiler-rt] Force ABI to libcxxabi when building cxustom libc++

Follow-up to 458ead66dc37, which replaced the bespoke CMakeLists.txt
file for building a custom instrumented libc++ with an invocation of the
runtimes build.

In the the bespoke CMakeLists.txt, the LIBCXX_CXX_ABI setting was forced
to libcxxabi, but this was not done for the CMake invocation for the
runtimes build. This would cause CMake configuration issues on platforms
where the default LIBCXX_CXX_ABI setting is not libcxxabi, such as
FreeBSD.

Add `-DLIBCXX_CXX_ABI=libcxxabi` to that invocation, to make sure the
custom instrumented libc++ always uses the expected ABI.

Reviewed By: phosek

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

show more ...

Revert "[CMake] Update internal libc++ configuration"

This reverts commit e286fefa8caaddea521685a8de1879acca82c67c since
the issue affecting the sanitizer-ppc64le-linux builder is resolved.

[CMake] Update internal libc++ configuration

This is an attempt to address 458ead66dc378ee5b9cbeb453a9cb7c3de768b2e
by better matching the previous configuration.

[compiler-rt] Use the runtimes build for custom libc++

Some of the compiler-rt runtimes use custom instrumented libc++ build.
Use the runtimes build for building this custom libc++.

Differential Re

[compiler-rt] Use the runtimes build for custom libc++

Some of the compiler-rt runtimes use custom instrumented libc++ build.
Use the runtimes build for building this custom libc++.

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

show more ...

Revert "[compiler-rt] Use the runtimes build for custom libc++"

This reverts commit bda3f2dd763b06427dd2713aa062e356c9d7bdc6 since
it broke MSan tests.

[CMake] Specify byproducts for custom libcxx builds

These were removed in bda3f2dd763b06427dd2713aa062e356c9d7bdc6 but
are needed as it turned out for the MSan tests.

[compiler-rt] Use the runtimes build for custom libc++

Some of the compiler-rt runtimes use custom instrumented libc++ build.
Use the runtimes build for building this custom libc++.

Differential Re

[compiler-rt] Use the runtimes build for custom libc++

Some of the compiler-rt runtimes use custom instrumented libc++ build.
Use the runtimes build for building this custom libc++.

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

show more ...

[cmake] By default do not instrument compiler-rt if LLVM_BUILD_INSTRUMENTED_COVERAGE is ON

Applying the same rules as for LLVM_BUILD_INSTRUMENTED build in the cmake files.
By having this patch, we a

[cmake] By default do not instrument compiler-rt if LLVM_BUILD_INSTRUMENTED_COVERAGE is ON

Applying the same rules as for LLVM_BUILD_INSTRUMENTED build in the cmake files.
By having this patch, we are able to disable/enable instrument+coverage build
of the compiler-rt project when building instrumented LLVM.

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

show more ...

[compiler-rt] Produce the right arch suffix for arm baremetal

D98452 introduced a mismatch between clang expectations for
builtin name for baremetal targets on arm. Fix it by
adding a case for barem

[compiler-rt] Produce the right arch suffix for arm baremetal

D98452 introduced a mismatch between clang expectations for
builtin name for baremetal targets on arm. Fix it by
adding a case for baremetal. This now matches the output of
"clang -target armv7m-none-eabi -print-libgcc-file-name \
-rtlib=compiler-rt"

Reviewed By: mstorsjo

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

show more ...