https://reviews.llvm.org/D104808 set the alignment of long double to 64
bits. This is also the alignment specified in the LLVM data layout.
However, the alignment of __float128 was left at 128 bits.
I assume that this was just an oversight, rather than an intentional
divergence. The C ABI document currently does not make any statement
about `__float128`:
https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md
Since commit 613a077b05b8352a48695be295037306f5fca151, `flang` doesn't
build any longer on Solaris/amd64:
```
flang/lib/Evaluate/intrinsics-library.cpp:225:26:
error: address of overloaded function 'acos' does not match required type '__float128 (__float128)'
225 | FolderFactory<F, F{std::acos}>::Create("acos"),
| ^~~~~~~~~
```
That patch led to the version of `quadmath.h` deep inside `/usr/gcc/<N>`
to be found, thus `HAS_QUADMATHLIB` is defined. However, the `struct
HostRuntimeLibrary<__float128, LibraryVersion::Libm>` template is
guarded by `_POSIX_C_SOURCE >= 200112L || _XOPEN_SOURCE >= 600`, while
`clang` only predefines `_XOPEN_SOURCE=500`.
This code dates back to commit 0c1941cb055fcf008e17faa6605969673211bea3
back in 2012. Currently, this is long obsolete and `gcc` prefefines
`_XOPEN_SOURCE=600` instead since GCC 4.6 back in 2011.
This patch follows that.
Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.
arm-apple-none-macho uses DarwinTargetInfo which provides several Apple
specific macros. arm64-apple-none-macho however just uses the generic
AArch64leTargetInfo and doesn't get any of those macros. It's not clear
if everything from DarwinTargetInfo is desirable for
arm64-apple-none-macho, so make an AppleMachOTargetInfo to hold the
generic Apple macros and a few other basic things.
Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.
An open question is whether we can backport this to LLVM 19.x. After
all, adding new triplets to Triple sounds like an ABI change — though I
suppose we can minimize the risk of breaking something if we move new
enum values to the very end.
Introduce changes necessary for UEFI X86_64 target Clang driver.
Addressed the review comments originally suggested in Phabricator.
Differential Revision: https://reviews.llvm.org/D159541
This is a revert of ef5e7f90ea4d5063ce68b952c5de473e610afc02 which was a
temporary partial revert of 77ac823fd285973cfb3517932c09d82e6a32f46d.
The le32 and le64 targets are no longer necessary to retain, so this
removes them entirely.
This aligns Fuchsia targets with other similar OS targets such as
Linux. Fuchsia's libc already uses unsigned rather than the
compiler-provided __WINT_TYPE__ macro for its wint_t typedef, so
this just makes the compiler consistent with the OS's actual ABI.
The only known manifestation of the mismatch is -Wformat warnings
for %lc no matching wint_t arguments.
The closest thing I could see to existing tests for each target's
wint_t type setting was the predefine tests that check various
macros including __WINT_TYPE__ on a per-machine and/or per-OS
basis. While the setting is done per-OS in most of the target
implementations rather than actually varying by machine, the only
existing tests for __WINT_TYPE__ are in per-machine checks that
are also wholly or partly tagged as per-OS. x86_64 and riscv64
tests for respective *-linux-gnu targets now check for the same
definitions in the respective *-fuchsia targets. __WINT_TYPE__
is not among the type checked in the aarch64 tests and those lack
a section that's specifically tested for aarch64-linux-gnu; if
such is added then it can similarly be made to check for most or
all of the same value on aarch64-fuchsia as aarch64-linux-gnu.
But since the actual implementation of choosing the type is done
per-OS and not per-machine for the three machines with Fuchsia
target support, the x86 and riscv64 tests are already redundantly
testing that same code and seem sufficient.
This is an attempt at rebooting https://reviews.llvm.org/D28990
I've included AutoUpgrade changes to modify the data layout to satisfy the compatible layout check. But this does mean alloca, loads, stores, etc in old IR will automatically get this new alignment.
This should fix PR46320.
Reviewed By: echristo, rnk, tmgross
Differential Revision: https://reviews.llvm.org/D86310
Derived from D49481, but added tests and simplified the diff a bit; isPIEDefault
can just be removed. Also looking through their upstream patches I noticed PIC
is also enabled.
Reviewed By: nielx
Differential Revision: https://reviews.llvm.org/D159390
After this D108637 and with FreeBSD -current and now 14 dropping support for
CloudABI I think it is time to consider deleting the CloudABI support.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158920
After looking at this further I think the Ananas support should be removed.
They stopped using Clang. There have never been any releases either; as in
source only, and the backend is not maintained.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D158946
Minix is a ToolChain that was added back in 2010 but has been
unmaintained with no test. The constructed command line contains
/usr/gnu/include/c++/4.4.3 and CompilerRT-Generic which are unlikely
working for a long time.
Contiki is a barebone ToolChain that just enables safestack.
This doesn't justify a new ToolChain.
Remove these ToolChains so that their target triples will use Generic_ELF instead.
If these developers feel like having an updated llvm-project is useful,
fixing other build issues and adding a new ToolChain is much better than
having the unmaintained ToolChains.
Reviewed By: brad
Differential Revision: https://reviews.llvm.org/D158461
Add the required options and macros to the compilation step for z/os.
Reviewed By: abhina.sreeskantharajan, fanbo-meng
Differential Revision: https://reviews.llvm.org/D153582
Fix several instances of macros being defined multiple times
in several targets. Most of these are just simple duplication in a
TargetInfo or OSTargetInfo of things already defined in
InitializePredefinedMacros or InitializeStandardPredefinedMacros,
but there are a few that aren't:
* AArch64 defines a couple of feature macros for armv8.1a that are
handled generically by getTargetDefines.
* CSKY needs to take care when CPUName and ArchName are the same.
* Many os/target combinations result in __ELF__ being defined twice.
Instead define __ELF__ just once in InitPreprocessor based on
the Triple, which already knows what the object format is based
on os and target.
These changes shouldn't change the final result of which macros are
defined, with the exception of the changes to __ELF__ where if you
explicitly specify the object type in the triple then this affects
if __ELF__ is defined, e.g. --target=i686-windows-elf results in it
being defined where it wasn't before, but this is more accurate as an
ELF file is in fact generated.
Differential Revision: https://reviews.llvm.org/D150966
The alignment of function pointers was added to the Datalayout by
D57335 but currently is unset for the Power target. This will cause us
to compute a conservative minimum alignment of one if places like
Value::getPointerAlignment.
This patch implements the function pointer alignment in the Datalayout
for the Power backend and Power targets in clang, so we can query the
value for a particular Power target.
We come up with the correct value one of two ways:
- If the target uses function descriptor objects (i.e. ELFv1 & AIX ABIs),
then a function pointer points to the descriptor, so use the alignment
we would emit the descriptor with.
- If the target doesn't use function descriptor objects (i.e. ELFv2), a
function pointer points to the global entry point, so use the minimum
alignment for code on Power (i.e. 4-bytes).
Reviewed By: nemanjai
Differential Revision: https://reviews.llvm.org/D147016
Add a clang part of OpenHarmony target
Related LLVM part: D138202
~~~
Huawei RRI, OS Lab
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145227
This change had tests that break whenever LLVM_ENABLE_LINKER_BUILD_ID is
set, as is the case in the Fuchsia target.
This reverts commits:
f81317a54586dbcef0c14cf512a0770e8ecaab3d
72474afa27570a0a1307f3260f0187b703aa6d84
Add a clang part of OpenHarmony target
Related LLVM part: D138202
~~~
Huawei RRI, OS Lab
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D145227
There is already a GCC compatibility gap on AIX, & GCC compatibility is
not a concern on z/OS. GCC compatibility is not sufficient motivation
for breaking ABI on AIX and z/OS. This opts out of changes introduced in
https://reviews.llvm.org/D119051. For AIX only, also opt out of D117616
(which z/OS had picked up at the time ABI stabilization occurred).
Differential Revision: https://reviews.llvm.org/D142358
The AST/conditionally-trivial-smfs tests look a bit questionable, but
are consistent with GCC's POD-ness, at least as far as packing is
concerned: https://godbolt.org/z/36nqPMbKM
(questionable because it looks like the type would be non-copyable, so
how could it be pod? But the calling convention/pass by value seems to
work correctly (local testing verifies that this behavior is preserved
even with this patch: https://godbolt.org/z/3Pa89zsv6 ))
Differential Revision: https://reviews.llvm.org/D119051
Currently, compiling a program with the `-pg` flag will result in an
undefined symbol error for `.mcount`. This revision fixes the call to
use `__mcount`, which requires a pointer argument to a pointer-sized
object (unique per inserted call) on AIX.
This is only a partial fix. This patch should fix the `-pg` flag's
behaviour on AIX to work with code you are compiling, but it will not
link against standard libraries with `mcount` instrumentation calls. The
next step is to add profiled libraries to the linker search paths in the
Clang driver for the AIX toolchain when linking with `-pg`.
Differential Review: https://reviews.llvm.org/D135384
(& remove PSPTargetInfo because it's unused - it had the wrong ctor in
it anyway, so wouldn't've been able to be instantiated - must've
happened due to bitrot over the years)
