Summary:
There's some static checks on the library, we can't do offloading with
`libgomp` for OpenMP. This patch specifies the library for the tests to
avoid this breaking tests.
JIT support for OpenMP offloading was introduced in D139287. This patch
adds a simple flag that enables this mode. It simply requires enabling
`-foffload-lto` mode and `--embed-bitcode` in the linker wrapper. This
option implies LTO if it is not enabled.
Reviewed By: jdoerfert
Differential Revision: https://reviews.llvm.org/D141158
The CACOP instruction is mainly used for cache initialization
and cache-consistency maintenance.
Depends on D140872
Reviewed By: SixWeining
Differential Revision: https://reviews.llvm.org/D140527
MC default was flipped in 2016.
CMake ENABLE_X86_RELAX_RELOCATIONS defaults to on in 2020 (c41a18cf61790fc898dcda1055c3efbf442c14c0).
It makes sense for the CodeGenOptions::RelaxELFRelocations to match, so
that most -cc1/-cc1as command lines won't have this option.
This also fixes a minor issue: -fno-plt -S will now use GOT for
__tls_get_addr calls, matching -fno-plt -c.
Some macOS projects use -Xparser even if it leads to a
-Wunused-command-line-argument warning. It doesn't justify adding a broad Joined
`-X` (IgnoredGCCCompat) as GCC doesn't really support these arbitrary `-X`
options.
Note: `-Xcompiler foo` is a GNU libtool option, not a driver option.
It is misused by some ChromeOS packages (but not by Gentoo).
Keep it for a while.
It seems that GCC < 4.6 reports g++: unrecognized option '-Xfoo' but exit with 0.
GCC >= 4.6 reports g++: error: unrecognized option '-Xfoo' and exits with 1.
It never supports -Xcompiler or -Xparser, so `IgnoredGCCCompat` is not justified.
Differential Revision: https://reviews.llvm.org/D140224
This reverts commit 9739bb81aed490bfcbcbbac6970da8fb7232fd34.
It causes `.module is not permitted after generating code`
for Linux kernel's `ARCH=mips 32r1_defconfig` clang+GNU as build.
It's confirmed as a defect, but the proper fix needs time to sort out.
This reverts commit e43924a75145d2f9e722f74b673145c3e62bfd07.
Reason: Patch broke the MSan buildbots. More information is available on
the original phabricator review: https://reviews.llvm.org/D127812
Previously, we would be passing down -stdlib=libc++ from the Driver
to CC1 whenever the default standard library on the platform was libc++,
even if -stdlib= had not been passed to the Driver. This meant that we
would pass -stdlib=libc++ in nonsensical circumstances, such as when
compiling C code.
This logic had been added in b534ce46bd40 to make sure that header
search paths were set up properly. However, since libc++ is now the
default Standard Library on Darwin, passing this explicitly is not
required anymore. Indeed, if no -stdlib= is specified, CC1 will end
up using libc++ if it queries which standard library to use, without
having to be told.
Not passing -stdlib= at all to CC1 on Darwin should become possible
once CC1 stops relying on it to set up framework search paths.
Furthermore, this commit also removes a diagnostic checking whether the
deployment target is too old to support libc++. Nowadays, all supported
deployment targets use libc++ and compiling with libstdc++ is not
supported anymore. The Driver was the wrong place to issue this
diagnostic since it doesn't know whether libc++ will actually be linked
against (e.g. C vs C++), which would lead to spurious diagnostics.
Given that these targets are not supported anymore, we simply drop
the diagnostic instead of trying to refactor it into CC1.
This is a re-application of 6540f32db09c which had been reverted in
49dd02bd0819 because it broke a compiler-rt test. The test had broken
because we were compiling C code and passing -stdlib=libc++, which Clang
will now warn about.
rdar://103198514
Differential Revision: https://reviews.llvm.org/D139938
This broke the instrprof-darwin-exports.c test on mac, see e.g.
https://green.lab.llvm.org/green/job/clang-stage1-RA/32351/
> Previously, we would be passing down -stdlib=libc++ from the Driver
> to CC1 whenever the default standard library on the platform was libc++,
> even if -stdlib= had not been passed to the Driver. This meant that we
> would pass -stdlib=libc++ in nonsensical circumstances, such as when
> compiling C code.
>
> This logic had been added in b534ce46bd40 to make sure that header
> search paths were set up properly. However, since libc++ is now the
> default Standard Library on Darwin, passing this explicitly is not
> required anymore. Indeed, if no -stdlib= is specified, CC1 will end
> up using libc++ if it queries which standard library to use, without
> having to be told.
>
> Not passing -stdlib= at all to CC1 on Darwin should become possible
> once CC1 stops relying on it to set up framework search paths.
>
> Furthermore, this commit also removes a diagnostic checking whether the
> deployment target is too old to support libc++. Nowadays, all supported
> deployment targets use libc++ and compiling with libstdc++ is not
> supported anymore. The Driver was the wrong place to issue this
> diagnostic since it doesn't know whether libc++ will actually be linked
> against (e.g. C vs C++), which would lead to spurious diagnostics.
> Given that these targets are not supported anymore, we simply drop
> the diagnostic instead of trying to refactor it into CC1.
>
> rdar://103198514
>
> Differential Revision: https://reviews.llvm.org/D139938
This reverts commit 6540f32db09cf6b367812642fbd91d44cbb6638d.
Previously, we would be passing down -stdlib=libc++ from the Driver
to CC1 whenever the default standard library on the platform was libc++,
even if -stdlib= had not been passed to the Driver. This meant that we
would pass -stdlib=libc++ in nonsensical circumstances, such as when
compiling C code.
This logic had been added in b534ce46bd40 to make sure that header
search paths were set up properly. However, since libc++ is now the
default Standard Library on Darwin, passing this explicitly is not
required anymore. Indeed, if no -stdlib= is specified, CC1 will end
up using libc++ if it queries which standard library to use, without
having to be told.
Not passing -stdlib= at all to CC1 on Darwin should become possible
once CC1 stops relying on it to set up framework search paths.
Furthermore, this commit also removes a diagnostic checking whether the
deployment target is too old to support libc++. Nowadays, all supported
deployment targets use libc++ and compiling with libstdc++ is not
supported anymore. The Driver was the wrong place to issue this
diagnostic since it doesn't know whether libc++ will actually be linked
against (e.g. C vs C++), which would lead to spurious diagnostics.
Given that these targets are not supported anymore, we simply drop
the diagnostic instead of trying to refactor it into CC1.
rdar://103198514
Differential Revision: https://reviews.llvm.org/D139938
Implement the proposed UAX Profile
"Mathematical notation profile for default identifiers".
This implements a not-yet approved Unicode for a vetted
UAX31 identifier profile
https://www.unicode.org/L2/L2022/22230-math-profile.pdf
This change mitigates the reported disruption caused
by the implementation of UAX31 in C++ and C2x,
as these mathematical symbols are commonly used in the
scientific community.
Fixes#54732
Reviewed By: tahonermann, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D137051
The ClangBuiltLinux project relies on `-mcpu=405`. Before https://reviews.llvm.org/D139720, `clang` treated `-mcpu=405` implicitly in the same way as `-mcpu=generic`, because `405` was an unknown value and `clang` did not validate unknown input values. https://reviews.llvm.org/D139720 added the validation of `-mcpu` input value, and `clang` now generates an error with `-mcpu=405`. For further details of the problem, see https://github.com/ClangBuiltLinux/linux/issues/1771.
This patch adds support of `-mcpu=405` explicitly, and treats it as an equivalent of `-mcpu=generic`.
Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D140080
When we use llc or lld to compiler IR files, the features +nan2008 and +fpxx/+fp64 are not used.
Thus wrong format files are produced.
In IR files, the attributes are only set for function while not the whole compile units.
So we output `.nan 2008` and `.module fp=xx/64` before every function.
`isFPXXDefault`: for o32, the FPXX should always be the default, no matter about the vendors.
Of course some distributions with FP64 default enabled should be listed explicit.
Let's add them in future if we know about one.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D138179
This adds some SPARC feature flags to clang, for those that we have in common with GCC:
-m[no-]fpu
-m[no-]fsmuld
-m[no-]popc
-m[no-]vis
-m[no-]vis2
-m[no-]vis3
-m[hard/soft]-quad-float
All have the same meanings as GCC's options (https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html).
This fixes, among other things, the -mno-fpu part of bug #40792
Reviewed By: nickdesaulniers
Differential Revision: https://reviews.llvm.org/D139768
SCR1 is available at https://github.com/syntacore/scr1
'syntacore-scr1-base' corresponds to SCR1_CFG_RV32IC_BASE,
'syntacore-scr1-max' corresponds to SCR1_CFG_RV32IMC_MAX.
SCR1_CFG_RV32EC_MIN is RV32EC, which is currently unsupported.
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D139302
When -mabi=ieeelongdouble is enabled by default, libc++ does not support
-mabi=ibmlongdouble.
Reviewed By: qiucf
Differential Revision: https://reviews.llvm.org/D139450
Currently `ppc::getPPCTargetCPU` returns an empty string when it encounters an unknown value passed to `-mcpu`. This causes `clang` to ignore unknown `-mcpu` values silently.
This patch changes the behaviour of `ppc::getPPCTargetCPU` so that it passes the unknown option to the target info, so the target info can actually check if the CPU string is supported, and report an error when encountering unknown/unsupported CPU string.
Reviewed By: jamieschmeiser
Differential Revision: https://reviews.llvm.org/D139720
Also add 'system-zos' as a lit feature and use it where needed.
Part of the project to eliminate special handling for triples in lit
expressions.
Differential Revision: https://reviews.llvm.org/D139444
If you build compiler-rt with LLVM_ENABLE_PER_TARGET_RUNTIME_DIR then
the library filename will be "libclang_rt.builtins.a" instead of
"libclang_rt.builtins-<ARCH>.a"
The ToolChain::getCompilerRT method uses the "libclang_rt.builtins.a"
name if it can find the file in the library directories. If it can't
then it falls back to using "libclang_rt.builtins-<ARCH>.a". This
change adds the library directory such that "libclang_rt.builtins.a"
can be found.
Differential Revision: https://reviews.llvm.org/D139822
The option does not change IR but affect object file generation. Without a
backend option the option is a no-op for in-process ThinLTO.
The problem is known and there are many options similar to -fstack-size-section.
That said, -fstack-size-section has relatively wider adoption, so it probably
makes sense to have custom code for it.
Close https://github.com/llvm/llvm-project/issues/59424
Allow TSan in clang driver for X86_64 WatchOS simulator.
It was already functional, and Apple's downstream fork of clang allows it, but that change had not made it upstream yet.
Reviewed By: jyknight, yln
Differential Revision: https://reviews.llvm.org/D139652
This reverts commit 6b992bcce0c5a86f57c83dd8d0ac9e63bcfc5521.
Test fails on macOS where ar doesn't want to create empty archives,
see https://reviews.llvm.org/D137275#3974489
Leaves the implementation and tests files in-place for right now, but
deletes the ability to build the old sanitizer-common based scudo. This
has been on life-support for a long time, and the newer scudo_standalone
is much better supported and maintained.
Also patches up some GWP-ASan wording, primarily related to the fact
that -fsanitize=scudo now is scudo_standalone, and therefore the way to
reference the GWP-ASan options through the environment variable has
changed.
Future follow-up patches will delete the original scudo, and migrate all
its tests over to be part of the scudo_standalone test suite.
Reviewed By: vitalybuka
Differential Revision: https://reviews.llvm.org/D138157
AIX and OpenBSD seem to use -p. For most targets (at least FreeBSD and Linux),
-p is legacy (GCC freebsd has a warning). We don't want the uses to grow, so
making -p an alias for -pg is not recommended. I think the uses are small.
Reviewed By: mgorny
Differential Revision: https://reviews.llvm.org/D138255
Extends the Asm reader/writer to support reading and writing the
'.memtag' directive (including allowing it on internal global
variables). Also add some extra tooling support, including objdump and
yaml2obj/obj2yaml.
Test that the sanitize_memtag IR attribute produces the expected asm
directive.
Uses the new Aarch64 MemtagABI specification
(https://github.com/ARM-software/abi-aa/blob/main/memtagabielf64/memtagabielf64.rst)
to identify symbols as tagged in object files. This is done using a
R_AARCH64_NONE relocation that identifies each tagged symbol, and these
relocations are tagged in a special SHT_AARCH64_MEMTAG_GLOBALS_STATIC
section. This signals to the linker that the global variable should be
tagged.
Reviewed By: fmayer, MaskRay, peter.smith
Differential Revision: https://reviews.llvm.org/D128958
A drive-by change in 53c98d85a8a609552448043d5512e70313b1eb1b made
-stdlib++-isystem be suppressed by -nostdinc and -nostdlibinc in
addition to -nostdinc++. However, that's contrary to the intent of the
flag. It's common to provide your own C++ headers (e.g. when building
libc++ by itself or as a compiler-rt dependency) but rely on the system
C headers, and having -stdlib++-isystem only look at -nostdinc++ allows
us to customize both the C header path (via -nostdinc or -nostdlibinc)
and the C++ header path (via -stdlib++-isystem) at the toolchain level
but still let users of the toolchain provide their own C++ headers. Add
a comment explaining the rationale to make it clearer.
