Generate outline atomics if compiling for armv8-a non-LSE AArch64 Linux
(including Android) targets to use LSE instructions, if they are available,
at runtime. Library support is checked by clang driver which doesn't enable
outline atomics if no proper libraries (libgcc >= 9.3.1 or compiler-rt) found.
Differential Revision: https://reviews.llvm.org/D93585
clang-cl already defaults to C17 for .c files, but no harm
in accepting these flags. Fixes PR48185.
Differential Revision: https://reviews.llvm.org/D95575
On non-Windows platforms, --sysroot can be used to make the compiler use
a single, hermetic directory for all header and library files.
This is useful, but difficult to do on Windows. After D95472 it's
possible to achieve this with two flags:
out/gn/bin/clang-cl win.c -fuse-ld=lld \
/vctoolsdir path/to/VC/Tools/MSVC/14.26.28801 \
/winsdkdir path/to/win_sdk
But that's still cumbersome: It requires two flags instead of one, and
it requires writing down the (changing) VC/Tools/MSVC version.
This adds a new `/winsysroot <dir>` flag that's effectively an alias to
these two flags. With this, building against a hermetic Windows
toolchain only needs:
out/gn/bin/clang-cl win.c -fuse-ld=lld /winsysroot path
`/winsysroot <dir>` is the same as adding
/vctoolsdir <dir>/VC/Tools/MSVC/<vctoolsver>
/winsdkdir <dir>/Windows Kits/<winsdkmajorversion>
`<vctoolsver>` is taken from `/vctoolsversion` if passed, or else it's
the name of the directory in `<dir>/VC/Tools/MSVC` that's the highest
numeric tuple.
`<winsdkmajorversion>` is the major version in /winsdkversion if passed,
else it's the name of the directory in `<dir>/Windows Kits` that's the
highest number.
So `/winsysroot <path>` requires this subfolder structure:
path/
VC/
Tools/
MSVC/
14.26.28801 (or another number)
include/
...
Windows Kits/
10/
Include/
10.0.19041.0/ (or another number)
um/
...
Lib/
10.0.19041.0/ (or another number)
um/
x64/
...
...
Differential Revision: https://reviews.llvm.org/D95534
On z/OS, the following error message is not matched correctly in lit tests.
```
EDC5129I No such file or directory.
```
This patch uses a lit config substitution to check for platform specific error messages.
Reviewed By: muiez, jhenderson
Differential Revision: https://reviews.llvm.org/D95246
Clang test Driver/macos-apple-silicon-slice-link-libs-darwin-only.cpp
assumes the target is darwin when the host is darwin which is not
necessarily the case, causing the test to fail when it is not. This
commit adds a -triple argument to the clang invocation to ensure the
target is darwin.
Reviewed By: hans
Differential Revision: https://reviews.llvm.org/D94396
with fix to test case and stringrefs.
Currently (for codeview) lambdas have a string like `<lambda_0>` in
their mangled name, and don't have any display name. This change uses the
`<lambda_0>` as the display name, which helps distinguish between lambdas
in -gline-tables-only, since there are no linkage names there.
It also changes how we display lambda names; previously we used
`<unnamed-tag>`; now it will show `<lambda_0>`.
I added a function to the mangling context code to create this string;
for Itanium it just returns an empty string.
Bug: https://bugs.llvm.org/show_bug.cgi?id=48432
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D95187
This reverts 9b21d4b943
Currently (for codeview) lambdas have a string like `<lambda_0>` in
their mangled name, and don't have any display name. This change uses the
`<lambda_0>` as the display name, which helps distinguish between lambdas
in -gline-tables-only, since there are no linkage names there.
It also changes how we display lambda names; previously we used
`<unnamed-tag>`; now it will show `<lambda_0>`.
I added a function to the mangling context code to create this string;
for Itanium it just returns an empty string.
Bug: https://bugs.llvm.org/show_bug.cgi?id=48432
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D95187
The only test that needed change had 'QUAL' as an unused prefix. The
rest of the changes are to simplify the prefix lists.
Differential Revision: https://reviews.llvm.org/D95499
If an initial value is given for a bitfield that does not fit in the
bitfield, the value should be truncated. Constant folding for
expressions did not account for this truncation in the case of union
member functions, despite a warning being emitted. In some contexts,
evaluation of expressions was not enabled unless C++11, ROPI or RWPI
was enabled.
Differential Revision: https://reviews.llvm.org/D93101
The Clang enable_if extension is mangled as an <extended-qualifier>,
which is supposed to contain <template-args>. However, we were
unconditionally emitting X/E around its arguments, neglecting the fact
that <expr-primary> should be emitted directly without the surrounding
X/E.
Differential Revision: https://reviews.llvm.org/D95488
Previously, we were emitting an extraneous X .. E in <template-arg>
around an <expr-primary> if the template argument was constructed from
an expression (rather than an already-evaluated literal value). In
such a case, we would then e.g. emit 'XLi0EE' instead of 'Li0E'.
We had one special-case for DeclRefExpr expressions, in particular, to
omit them the mangled-name without the surrounding X/E. However,
unfortunately, that special case also triggered for ParmVarDecl (a
subtype of VarDecl), and _incorrectly_ emitted 'L_Z .. E' instead of
the proper 'Xfp_E'.
This change causes mangleExpression itself to be responsible for
emitting X/E around non-primary expressions, which removes the
special-case, and corrects both these problems.
Differential Revision: https://reviews.llvm.org/D95487
The two operations have acted differently since Clang 8, but were
unfortunately mangled the same. The new mangling uses new "vendor
extended expression" syntax proposed in
https://github.com/itanium-cxx-abi/cxx-abi/issues/112
GCC had the same mangling problem, https://gcc.gnu.org/PR88115, and
will hopefully be switching to the same mangling as implemented here.
Additionally, fix the mangling of `__uuidof` to use the new extension
syntax, instead of its previous nonstandard special-case.
Adjusts the demangler accordingly.
Differential Revision: https://reviews.llvm.org/D93922
More study has discovered this to not actually be useful: because
current C++20 implementations reject `#ifdef __VA_OPT__`, this can't
really be used as a feature-test mechanism. And it's not too hard to
detect __VA_OPT__ without this, for example:
#define THIRD_ARG(a, b, c, ...) c
#define HAS_VA_OPT(...) THIRD_ARG(__VA_OPT__(,), 1, 0, )
#if HAS_VA_OPT(?)
Partially reverts 0436ec2128.
These changes are intended to give code a path to move away from the GNU
,##__VA_ARGS__ extension, which is non-conforming in some situations and
which we'd like to disable in our conforming mode in those cases.
In Clang today, we parse the different attribute syntaxes
(__attribute__, __declspec, and [[]]) in a fairly rigid order. This
leads to confusion for users when they guess the order incorrectly,
and leads to bug reports like PR24559 or necessitates changes like
D94788.
This patch adds a helper function to allow us to more easily parse
attributes in arbitrary order, and then updates all of the places
where we would parse two or more different syntaxes in a rigid order to
use the helper method. The patch does not attempt to handle Microsoft
attributes ([]) because those are ambiguous with other code constructs
and we don't have any attributes that use the syntax.
This reverts commit f4537935dc.
This reverts commit b43c26d036.
This GNU and MSVC extension turns out to be very popular. Most projects
are not using C++20, so cannot use the new __VA_OPT__ feature to be
standards conformant. The other workaround, using -std=gnu*, enables too
many language extensions and isn't viable.
Until there is a way for users to get the behavior provided by the
`, ## __VA_ARGS__` extension in the -std=c++17 and earlier language
modes, we need to revert this.
llvmArchToWindowsSDKArch() returns "" for non-intel non-arm archs.
We're checking for "/fake/lib/" which is followed by the result
of that function -- but if that returns an empty string, then that
trailing slash isn't there. As fix, just explicitly pass a triple
that's intel or arm (I randomly chose aarch64). Since the test runs
with -###, that arch doesn't have to be in LLVM_TARGETS_TO_BUILD.
These do for the Windows SDK path what D85998 did for
%VCToolsInstallDir% with /vctoolsdir: Offer a way to set them with an
explicit commandline switch.
With this (and /vctoolsdir), it's possible to compile and link
against hermetic vctools and winsdk directories with:
out/gn/bin/clang-cl win.c -fuse-ld=lld \
/vctoolsdir path/to/VC/Tools/MSVC/14.26.28801 \
/winsdkdir path/to/win_sdk
compared to a long list of -imsvc and /link /libpath: flags.
While here:
- Change the case of the "Include" folder inside the windows sdk
from "include" to "Include" to match on-disk case. Since the
Windows file system is case-insensitive this isn't a behavior
change, it's just a bit cleaner.
- Add libpath tests to the /vctoolsdir
- Add a FIXME about reading env vars for win sdk and ucrt sdk
if these flags aren't present, to match the VCToolsInstallDir
logic
We should also cache all these computed paths in the driver instead
of computing them every time they're queried, but that's for a future
patch.
It'd also be nice to invent a /winsysroot: flag that sets both
/vctoolsdir: and /winsdkdir: to some well-known subdirectory.
That's for a future patch as well.
Differential Revision: https://reviews.llvm.org/D95472
The included test case triggered a sign assertion on the result in
`Success()`. This was caused by the APSInt created for a bitcast
having its signedness bit inverted. The second APSInt constructor
argument is `isUnsigned`, so invert the result of
`isSignedIntegerType`.
Relanding this patch after reverting. The test case had to be updated
to be insensitive to 32/64-bit extractelement indices.
Differential Revision: https://reviews.llvm.org/D95135
This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
sanitizer special case list format to select which files and functions
to instrument, and relies on the new noprofile IR attribute to exclude
functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
The unwinder used by the crash handler on versions of Android prior to
API 29 did not correctly handle binaries built with rosegment, which is
enabled by default for LLD. Android only supports LLD, so it's not an
issue that this flag is not accepted by other linkers.
Reviewed By: srhines
Differential Revision: https://reviews.llvm.org/D95166
There are two use cases.
Assembler
We have accrued some code gated on MCAsmInfo::useIntegratedAssembler(). Some
features are supported by latest GNU as, but we have to use
MCAsmInfo::useIntegratedAs() because the newer versions have not been widely
adopted (e.g. SHF_LINK_ORDER 'o' and 'unique' linkage in 2.35, --compress-debug-sections= in 2.26).
Linker
We want to use features supported only by LLD or very new GNU ld, or don't want
to work around older GNU ld. We currently can't represent that "we don't care
about old GNU ld". You can find such workarounds in a few other places, e.g.
Mips/MipsAsmprinter.cpp PowerPC/PPCTOCRegDeps.cpp X86/X86MCInstrLower.cpp
AArch64 TLS workaround for R_AARCH64_TLSLD_MOVW_DTPREL_* (PR ld/18276),
R_AARCH64_TLSLE_LDST8_TPREL_LO12 (https://bugs.llvm.org/show_bug.cgi?id=36727https://sourceware.org/bugzilla/show_bug.cgi?id=22969)
Mixed SHF_LINK_ORDER and non-SHF_LINK_ORDER components (supported by LLD in D84001;
GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=16833 may take a while before available).
This feature allows to garbage collect some unused sections (e.g. fragmented .gcc_except_table).
This patch adds `-fbinutils-version=` to clang and `-binutils-version` to llc.
It changes one codegen place in SHF_MERGE to demonstrate its usage.
`-fbinutils-version=2.35` means the produced object file does not care about GNU
ld<2.35 compatibility. When `-fno-integrated-as` is specified, the produced
assembly can be consumed by GNU as>=2.35, but older versions may not work.
`-fbinutils-version=none` means that we can use all ELF features, regardless of
GNU as/ld support.
Both clang and llc need `parseBinutilsVersion`. Such command line parsing is
usually implemented in `llvm/lib/CodeGen/CommandFlags.cpp` (LLVMCodeGen),
however, ClangCodeGen does not depend on LLVMCodeGen. So I add
`parseBinutilsVersion` to `llvm/lib/Target/TargetMachine.cpp` (LLVMTarget).
Differential Revision: https://reviews.llvm.org/D85474
For Clang synthesized `__va_list_tag` (`CreateX86_64ABIBuiltinVaListDecl`),
its DW_AT_decl_file/DW_AT_decl_line are arbitrarily set from `CurLoc`.
In a stage 2 `-DCMAKE_BUILD_TYPE=Debug` clang build, I observe that
in driver.cpp, DW_AT_decl_file/DW_AT_decl_line may be set to an `#include` line
(the transitively included file uses va_arg (`__builtin_va_arg`)).
This seems arbitrary. Drop that.
Reviewed By: #debug-info, dblaikie
Differential Revision: https://reviews.llvm.org/D94735
This change implements support for applying profile instrumentation
only to selected files or functions. The implementation uses the
sanitizer special case list format to select which files and functions
to instrument, and relies on the new noprofile IR attribute to exclude
functions from instrumentation.
Differential Revision: https://reviews.llvm.org/D94820
From this patch (plus some landed patches), `deviceRTLs` is taken as a regular OpenMP program with just `declare target` regions. In this way, ideally, `deviceRTLs` can be written in OpenMP directly. No CUDA, no HIP anymore. (Well, AMD is still working on getting it work. For now AMDGCN still uses original way to compile) However, some target specific functions are still required, but they're no longer written in target specific language. For example, CUDA parts have all refined by replacing CUDA intrinsic and builtins with LLVM/Clang/NVVM intrinsics.
Here're a list of changes in this patch.
1. For NVPTX, `DEVICE` is defined empty in order to make the common parts still work with AMDGCN. Later once AMDGCN is also available, we will completely remove `DEVICE` or probably some other macros.
2. Shared variable is implemented with OpenMP allocator, which is defined in `allocator.h`. Again, this feature is not available on AMDGCN, so two macros are redefined properly.
3. CUDA header `cuda.h` is dropped in the source code. In order to deal with code difference in various CUDA versions, we build one bitcode library for each supported CUDA version. For each CUDA version, the highest PTX version it supports will be used, just as what we currently use for CUDA compilation.
4. Correspondingly, compiler driver is also updated to support CUDA version encoded in the name of bitcode library. Now the bitcode library for NVPTX is named as `libomptarget-nvptx-cuda_[cuda_version]-sm_[sm_number].bc`, such as `libomptarget-nvptx-cuda_80-sm_20.bc`.
With this change, there are also multiple features to be expected in the near future:
1. CUDA will be completely dropped when compiling OpenMP. By the time, we also build bitcode libraries for all supported SM, multiplied by all supported CUDA version.
2. Atomic operations used in `deviceRTLs` can be replaced by `omp atomic` if OpenMP 5.1 feature is fully supported. For now, the IR generated is totally wrong.
3. Target specific parts will be wrapped into `declare variant` with `isa` selector if it can work properly. No target specific macro is needed anymore.
4. (Maybe more...)
Reviewed By: JonChesterfield
Differential Revision: https://reviews.llvm.org/D94745
The previous implementation required that `-maltivec` be specified when using either `-mabi=vec-extabi` or `-mabi=vec-default`, this patch removes that requirement.
Reviewed By: cebowleratibm
Differential Revision: https://reviews.llvm.org/D94986
Whenever we enter a new OpenMP data environment we want to enter a
function to simplify reasoning. Later we probably want to remove the
entire specialization wrt. the if clause and pass the result to the
runtime, for now this should fix PR48686.
Reviewed By: ABataev
Differential Revision: https://reviews.llvm.org/D94315
We're choosing to take an opt-in approach for landing Relative VTables, so we'll
need asan-equivalent multilibs with relative vtables enabled. Afterwards, we can
just flip the switch in our build.
Differential Revision: https://reviews.llvm.org/D95253
As noted in D91913, MSVC implements the GNU behavior for
, ## __VA_ARGS__ as well. Do the same when `-fms-compatibility` is used.
Reviewed By: rsmith
Differential Revision: https://reviews.llvm.org/D95392
James Y Knight