This PR makes sure that when targeting arm64e on darwin platforms the
correct flags are set for the userspace platform ABI.
(cherry picked from commit 19c4e86f3e8582c3f087a9fec5ac036838e58ec4)
* Translate the following versions to 26.
* watchOS 12 -> 26
* visionOS 3 -> 26
* macos 16 -> 26
* iOS 19 -> 26
* tvOS 19 -> 26
* Emit diagnostics, but allow conversion when clients attempt to use
invalid gaps in OS versioning in availability.
* For target-triples, only allow "valid" versions for implicit
conversions.
This patch moves the CommonArgs utilities into a location visible by the
Frontend Drivers, so that the Frontend Drivers may share option parsing
code with the Compiler Driver. This is useful when the Frontend Drivers
would like to verify that their incoming options are well-formed and
also not reinvent the option parsing wheel.
We already see code in the Clang/Flang Drivers that is parsing and
verifying its incoming options. E.g. OPT_ffp_contract. This option is
parsed in the Compiler Driver, Clang Driver, and Flang Driver, all with
slightly different parsing code. It would be nice if the Frontend
Drivers were not required to duplicate this Compiler Driver code. That
way there is no/low maintenance burden on keeping all these parsing
functions in sync.
Along those lines, the Frontend Drivers will now have a useful mechanism
to verify their incoming options are well-formed. Currently, the
Frontend Drivers trust that the Compiler Driver is not passing back junk
in some cases. The Language Drivers may even accept junk with no error
at all. E.g.:
`clang -cc1 -mprefer-vector-width=junk test.c'
With this patch, we'll now be able to tighten up incomming options to
the Frontend drivers in a lightweight way.
---------
Co-authored-by: Cameron McInally <cmcinally@nvidia.com>
Co-authored-by: Shafik Yaghmour <shafik.yaghmour@intel.com>
To be able to handle all of the ways the platform & deployment version
can be represented in command line flags, the Darwin toolchain holds a
type `DarwinPlatform` to help represent them. This patch simplifies the
logic by:
* reducing the amount of work done between string & version tuples
conversions
* renaming variables to reduce confusion about what target triple
information is being manipulated.
* allowing implicit transformation of macOS10.16 -> 11, there are other
places in the compiler where this happens, and it was a bit confusing
that the driver didn't do that for the cc1 call.
This is not a major refactor, but more simple & common tweaks across the
file, in hopes to make it more readable.
These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
This PR addressed issue #140748 to support XRay instrumentation on the
host side when using offloading.
It makes the following changes:
- Initializes `XRayArgs` using the processed toolchain arguments instead
of the raw input.
- Removes the current caching mechanism of `XRayArgs` in the `ToolChain`
class, as this is error-prone and potential benefits are questionable.
For reference, `SanitizierArgs`, which is constructed in a similar
manner but is much more complex, does not use any caching.
- Adds driver tests to verify that XRay flags are set correctly with
offloading and `-Xarch_host`.
Move the Darwin framework search path logic from
InitHeaderSearch::AddDefaultIncludePaths to
DarwinClang::AddClangSystemIncludeArgs. Add a new -internal-iframework
cc1 argument to support the tool chain adding these paths.
Now that the tool chain is adding search paths via cc1 flag, they're
only added if they exist, so the Preprocessor/cuda-macos-includes.cu
test is no longer relevant.
Change Driver/driverkit-path.c and Driver/darwin-subframeworks.c to do
-### style testing similar to the darwin-header-search and
darwin-embedded-search-paths tests. Rename darwin-subframeworks.c to
darwin-framework-search-paths.c and have it test all framework search
paths, not just SubFrameworks.
Add a unit test to validate that the myriad of search path flags result
in the expected search path list.
Fixes https://github.com/llvm/llvm-project/issues/75638
Whether the SDK supports builtin modules is a property of the SDK
itself, and really has nothing to do with the target. This was already
worked around for Mac Catalyst, but there are some other more esoteric
non-obvious target-to-sdk mappings that aren't handled. Have the SDK
parse its OS out of CanonicalName and use that instead of the target to
determine if builtin modules are supported.
This PR is to improve the driver code to build `flang-rt` path by
re-using the logic and code of `compiler-rt`.
1. Moved `addFortranRuntimeLibraryPath` and `addFortranRuntimeLibs` to
`ToolChain.h` and made them virtual so that they can be overridden if
customization is needed. The current implementation of those two
procedures is moved to `ToolChain.cpp` as the base implementation to
default to.
2. Both AIX and PPCLinux now override `addFortranRuntimeLibs`.
The overriding function of `addFortranRuntimeLibs` for both AIX and
PPCLinux calls `getCompilerRTArgString` => `getCompilerRT` =>
`buildCompilerRTBasename` to get the path to `flang-rt`. This code
handles `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR` setting. As shown in
`PPCLinux.cpp`, `FT_static` is the default. If not found, it will search
and build for `FT_shared`. To differentiate `flang-rt` from `clang-rt`,
a boolean flag `IsFortran` is passed to the chain of functions in order
to reach `buildCompilerRTBasename`.
This PR partially reverts 83e180c and instead opts to not define the GPU entry
point on Darwin platforms. Marking `__llvm_write_custom_profile` as used
was causing issues on embedded platforms.
This pull request fixes an issue that was introduced in #93365.
`__llvm_write_custom_profile` visibility was causing issues on Darwin.
This function needs to be publicly accessible in order to be accessed by
libomptarget, so this pull request makes `__llvm_write_custom_profile`
an explicitly exported symbol on Darwin. Tested on M3 and X86 macs.
Summary:
Currently, `-Xarch_` is handled specially between different toolchains,
(i.e. Mach-O).
This patch unifies the handling so that it can be used generically.
The main benefit here is that we now have a more generic version of
`-Xopenmp-target=`, which should probably just be deprecated.
Additionally, it allows us to specially pass arguments to different
architectures for offloading.
This patch is done in preparation for making selecting offloading
toolchains more generic, this will be helpful while people are moving
toward compile jobs that include multiple toolchains (SPIR-V, AMDGCN,
NVPTX).
In the discussion around #116792, @rjmccall mentioned that ARCMigrate
has been obsoleted and that we could go ahead and remove it from Clang,
so this patch does just that.
AFAIK the only publicly released armv6 devices that ran Darwin were the
iPhone 2G, iPhone 3G, iPod touch 1, and the iPod touch 2, all of which
were iOS devices.
Partially fixes https://github.com/llvm/llvm-project/issues/59552 by
adding a new option `-fuse-lipo` that can specify the tool name to be
used by clang-driver for the lipo action. For example, pass
`-fuse-lipo=llvm-lipo` to use `llvm-lipo` instead of the default `lipo`.
Embedded development often needs to use a different C standard library,
replacing the existing one normally passed as -internal-externc-isystem.
This works fine for an apple-macos target, but apple-none-macho doesn't
work because the MachO driver doesn't implement
AddClangSystemIncludeArgs to add the resource directory as
-internal-isystem like most other drivers do. Move most of the search
path logic from Darwin and DarwinClang down into an AppleMachO toolchain
between the MachO and Darwin toolchains.
Also define __MACH__ for apple-none-macho, as Swift expects all MachO
targets to have that defined.
Embedded development often needs to use a different C standard library,
replacing the existing one normally passed as -internal-externc-isystem.
This works fine for an apple-macos target, but apple-none-macho doesn't
work because the MachO driver doesn't implement
AddClangSystemIncludeArgs to add the resource directory as
-internal-isystem like most other drivers do. Move most of the search
path logic from Darwin and DarwinClang down into an AppleMachO toolchain
between the MachO and Darwin toolchains.
Also define \_\_MACH__ for apple-none-macho, as Swift expects all MachO
targets to have that defined.
Introduces the SYCL based toolchain and initial toolchain construction
when using the '-fsycl' option. This option will enable SYCL based
offloading, creating a SPIR-V based IR file packaged into the compiled
host object.
This includes early support for creating the host/device object using
the new offloading model. The device object is created using the
spir64-unknown-unknown target triple.
New/Updated Options:
-fsycl Enables SYCL offloading for host and device
-fsycl-device-only
Enables device only compilation for SYCL
-fsycl-host-only
Enables host only compilation for SYCL
RFC Reference:
https://discourse.llvm.org/t/rfc-sycl-driver-enhancements/74092
This is a reland of: https://github.com/llvm/llvm-project/pull/107493
If a toolchain is configured with `DEFAULT_SYSROOT`, then this could
result in an unintended value for `-syslibroot` being passed to the
linker if the user manually sets `-isysroot` or `SDKROOT`.
Let's fix this by prioritising command line flags when determining
`-syslibroot` before checking `getSysRoot`.
Downstream bug report:
https://github.com/Homebrew/homebrew-core/issues/197277
Co-authored-by: Bo Anderson <mail@boanderson.me>
Co-authored-by: Bo Anderson <mail@boanderson.me>
This adds new Clang flags to support codegen (CG) data:
- `-fcodegen-data-generate{=path}`: This flag passes
`-codegen-data-generate` as a boolean to the LLVM backend, causing the
raw CG data to be emitted into a custom section. Currently, for LLD
MachO only, it also passes `--codegen-data-generate-path=<path>` so that
the indexed CG data file can be automatically produced at link time. For
linkers that do not yet support this feature, `llvm-cgdata` can be used
manually to merge this CG data in object files.
- `-fcodegen-data-use{=path}`: This flag passes
`-codegen-data-use-path=<path>` to the LLVM backend, enabling the use of
specified CG data to optimistically outline functions.
- The default `<path>` is set to `default.cgdata` when not specified.
This depends on https://github.com/llvm/llvm-project/pull/108733.
This is a patch for
https://discourse.llvm.org/t/rfc-enhanced-machine-outliner-part-2-thinlto-nolto/78753.
Introduce the `-fsanitize=realtime` flag in clang driver
Plug in the RealtimeSanitizer PassManager pass in Codegen, and attribute
a function based on if it has the `[[clang::nonblocking]]` function
effect.
Mac Catalyst is the iOS platform, but it builds against the macOS SDK
and so it needs to be checking the macOS SDK version instead of the iOS
one. Add tests against a greater-than SDK version just to make sure this
works beyond the initially supporting SDKs.
This patch fixes:
clang/lib/Driver/ToolChains/Darwin.cpp:2937:3: error: default label
in switch which covers all enumeration values
[-Werror,-Wcovered-switch-default]
The upcoming Apple SDK releases will support the clang built-in headers
being in the clang built-in modules: stop passing
-fbuiltin-headers-in-system-modules for those SDK versions.
Such searches can be costly and non-intuitive. We've seen complaints
from developers that they don't expect clang to find modules on their
own and not in search paths that developers provide. Keeping the search
of modulemaps in subdirectories for code completion as it provides
better user experience.
If you are defining module "UsefulCode" in
"include/UnrelatedName/module.modulemap", it is recommended to rename
the directory "UnrelatedName" to "UsefulCode". If you cannot do so, you
can add to "include/module.modulemap" a line like `extern module
UsefulCode "UnrelatedName/module.modulemap"`, so clang can find module
"UsefulCode" without checking each subdirectory in "include/".
rdar://106677321
---------
Co-authored-by: Jan Svoboda <jan@svoboda.ai>
On Darwin, -print-libgcc-file-name was returning a nonsensical result.
It would return the name of the library that would be used by the
default toolchain implementation, but that was something that didn't
exist on Darwin.
Fixing this requires initializing the Darwin toolchain before processing
`-print-libgcc-file-name`. Previously, the Darwin toolchain would only
be initialized when building the jobs for this compilation, which is too
late since `-print-libgcc-file-name` requires the toolchain to be
initialized in order to provide the right results.
rdar://90633749
Co-authored-by: Gabor Horvath <gaborh@apple.com>
Since `raw_string_ostream` doesn't own the string buffer, it is
desirable (in terms of memory safety) for users to directly reference
the string buffer rather than use `raw_string_ostream::str()`.
Work towards TODO item to remove `raw_string_ostream::str()`.
p.s. also remove some unneeded/dead code.
Since C++14 has been released for about nine years and most standard
libraries have implemented sized deallocation functions, it's time to
make this feature default again.
This is another try of https://reviews.llvm.org/D112921.
The original commit cf5a8b4 was reverted by 2e5035a due to some
failures (see #83774).
Fixes#60061
Since C++14 has been released for about nine years and most standard
libraries have implemented sized deallocation functions, it's time to
make this feature default again.
This is another try of https://reviews.llvm.org/D112921.
Fixes#60061
Summary:
We want to pass these GPU libraries by default if a certain offloading
toolchain is loaded for OpenMP. Previously I parsed this from the
arguments because it's only available in the compilation. This doesn't
really work for `native` and it's extra effort, so this patch just
passes in the `Compilation` as an extr argument and uses that. Tests
should be unaffected.
My #80527 mentioned that `InstalledDir` was weird in the
-canonical-prefixes mode. #70817 was a workaround to find the libc++
include path for a symlinked clang. After #80527, `InstalledDir` was
identical to `Dir` and was subsequently removed, the code change #70817
can be reverted.
