1. Added the missing XMEGA2 definition. The avr64 devices use xmega2 which has SPM(X) defined.
2. The avr16/avr32 devices do have SPM and SPMX features, but the current xmega3 definition has not.
Xmega3 is also used for modern attiny series which do not have SPM(X), so that is correct.
Leave the avr16/avr32 devices unchanged (using xmega3 to be in sync with gcc definitions).
Fixes https://github.com/llvm/llvm-project/issues/116116
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>
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 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`.
If '-r' is specified with target AVR:
1. Do not link to the avr-libc.
2. Do not emit some conflict options.
3. Do not emit any sub-target related address information/warning.
SubtargetFeature.h is currently part of MC while it doesn't depend on
anything in MC. Since some LLVM components might have the need to work
with target features without necessarily needing MC, it might be
worthwhile to move SubtargetFeature.h to a different location. This will
reduce the dependencies of said components.
Note that I choose TargetParser as the destination because that's where
Triple lives and SubtargetFeatures feels related to that.
This issues came up during a JITLink review (D149522). JITLink would
like to avoid a dependency on MC while still needing to store target
features.
Reviewed By: MaskRay, arsenm
Differential Revision: https://reviews.llvm.org/D150549
Different AVR devices have different data regions. Current clang
driver emits a default '-Tdata' option to the linker. This way
works fine if there is no user specified linker script, but it
will cause conflicts if there is one.
A better solution for setting the default data region to GNU ld
is defining symbol __DATA_REGION_ORIGIN__, which is expected by
GNU ld's default AVR linker script.
Fixes https://github.com/llvm/llvm-project/issues/60362
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D144533
value() has undesired exception checking semantics and calls
__throw_bad_optional_access in libc++. Moreover, the API is unavailable without
_LIBCPP_NO_EXCEPTIONS on older Mach-O platforms (see
_LIBCPP_AVAILABILITY_BAD_OPTIONAL_ACCESS).
This fixes clang.
This patch replaces:
return Optional<T>();
with:
return None;
to make the migration from llvm::Optional to std::optional easier.
Specifically, I can deprecate None (in my source tree, that is) to
identify all the instances of None that should be replaced with
std::nullopt.
Note that "return None" far outnumbers "return Optional<T>();". There
are more than 2000 instances of "return None" in our source tree.
All of the instances in this patch come from functions that return
Optional<T> except Archive::findSym and ASTNodeImporter::import, where
we return Expected<Optional<T>>. Note that we can construct
Expected<Optional<T>> from any parameter convertible to Optional<T>,
which None certainly is.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
Differential Revision: https://reviews.llvm.org/D138464
Move user specified inputs to the linking group in case
they and the stardard libraries have mutual reference.
Reviewed By: benshi001
Differential Revision: https://reviews.llvm.org/D127501
1. Support user specified linker (-fuse-ld)
2. Support user specified linker script (-T)
Reviewed By: MaskRay, haowei
Differential Revision: https://reviews.llvm.org/D126192
1. Support user specified linker (-fuse-ld)
2. Support user specified linker script (-T)
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D126192
Many options (-fsyntax-only, -E, -S, etc) skip the link action phase which the
existing condition does not account for.
Since the code no longer specifies OPT_c, I think a single RUN line about -c
not leading to a warning is sufficient. Adding one for all of -E,
-fsyntax-only, -S would be excessive.
Reviewed By: benshi001
Differential Revision: https://reviews.llvm.org/D122553
Many options (-fsyntax-only, -E, -S, etc) skip the link action phase which the
existing condition does not account for.
Since the code no longer specifies OPT_c, I think a single RUN line about -c
not leading to a warning is sufficient. Adding one for all of -E,
-fsyntax-only, -S would be excessive.
Reviewed By: benshi001
Differential Revision: https://reviews.llvm.org/D122553
AVR is baremetal environment, so the avr-libc does not support
'__cxa_atexit()'.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D118445
Now prints the list of known archs. This requires plumbing a Driver
arg through a few functions.
Also add two more convenience insert() overlods to StringMap.
Differential Revision: https://reviews.llvm.org/D109105
Search avr-libc path according to avr-gcc installation at first,
then other possible installed pathes.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D107682
On AVR, '.ctors' is used, not '.init_array'. Make this the default
unless specifically overridden by driver argument.
This matches gcc, and it matches the behavior in (e.g.) the NetBSD
driver (for certain OS variants).
Reviewed by: MaskRay
Differential Revision: https://reviews.llvm.org/D107610
