The larger alignment on this platform means that long double reports
a sizeof 16 bytes, but it's underlying size is really just the 10
bytes of `f80`
C doesn't give us a way to see the "underlying" size of a type, so
this has to be caught by hand or by monitoring runtime memory. Luckily,
x86 and x86-64 are the only platforms that seem to use a non-power-of-two
type like this.
This option can be used to produce a C backend build of the self-hosted
compiler, which only has the C backend enabled. Once the C backend is
capable of self-hosting, this will be a way for us to replace our stage1
codebase with a C backend build of self-hosted, which we can then use
for bootstrapping. See #5246 for more details.
Using this option right now results in a crash because the C backend is
not yet passing all the behavior tests.
CMake recognizes the CMAKE_PREFIX_PATH environment variable for some
things, and also the CMAKE_PREFIX_PATH cache variable for other things.
However, it does not relate these two things, i.e. if the environment
variable is set, CMake does not populate the cache variable in a
corresponding manner. Some package systems, such as Homebrew, set the
environment variable but not the cache variable. Furthermore, the
environment variable follows the system path separator, such as ':' on
POSIX and ';' on Windows, but the cache variable follows CMake's array
behavior, i.e. always ';' for a separator.
Closes#13242
This value corresponds to clang/gcc's `__alignof` (rather than
`_Alignof` which reports the minimum alignment). We don't use this
information yet, but it might be useful for implementing ABIs so it
is included here.
The Zig LLVM backend emits calls to softfloat methods with the "standard
compiler-rt" names. Rather than add complexity to the backend and
have to synchronize the naming scheme across all targets, the simplest
fix is just to export these symbols under both the "standard" and the
platform-specific naming convention.
This documents status of routines and adds the next work item
"Decimal float library routines", which are only recommended for
binary data. Complete absence of tests is also documented.
This does not document the various aliases, e.g. those for ARM.
Missing Integer library routines:
- __addvsi3
- __addvdi3
- __addvti3
- __addvdi3
- __addvti3
- __subvsi3
- __subvdi3
- __subvti3
- __subvdi3
- __subvti3
- __mulvsi3
- __mulvdi3
- __mulvti3
- __mulvdi3
- __mulvti3
Missing floating library routines:
- __powisf2
- __powidf2
- __powitf2
- __powixf2
Missing routines for symbol-level compatibility to gcc:
- __ashlsi3
- __ashrsi3
- __lshrsi3
cmp.zig was accidently being referenced twice, rather than importing
memcmp.zig. This means that its symbols were also not included in
the generated compiler-rt output.
1. If an object file was not compiled with `MH_SUBSECTIONS_VIA_SYMBOLS`
such a hand-written ASM on x86_64, treat the entire object file as
not suitable for dead code stripping aka a GC root.
2. If there are non-extern relocs within a section, treat the entire
section as a root, at least temporarily until we work out the exact
conditions for marking the atoms live.
This function is redundant with CType.sizeInBits(), and until the
previous commit they disagreed about the correct long double type
for several targets. Although they're all synced up now, it's much
simpler just to have a single source of truth.
These updates were made by testing against the `sizeof/_Alignof` reported
by Clang for all supported arch-OS-ABI combinations and correcting any
discrepancies.
This is bound to have a few errors (the recent long double fix for i386
Android is one example), but Clang is certainly not a bad place to start,
especially for our most popular targets.
