The Cygwin target is generally very similar to the MinGW target. The
default auto-import behavior, the default calling convention, the
`.dll.a` import library extension, the `__GXX_TYPEINFO_EQUALITY_INLINE`
pre-define by `g++`, and the long double configuration.
Co-authored-by: Mateusz Mikuła <oss@mateuszmikula.dev>
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.
-mcmodel= is supported for a few architectures. Reject the option for
other architectures.
* -mcmodel= is unsupported on x86-32.
* -mcmodel=large is unsupported for PIC on AArch64.
* -mcmodel= is unsupported for aarch64_32 triples.
* https://reviews.llvm.org/D67066 (for RISC-V) made
-mcmodel=medany/-mcmodel=medlow aliases for all architectures. Restrict
this to RISC-V.
* llvm/lib/Target/Sparc has some small/medium/large support, but the
values listed on https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html
had been supported before https://reviews.llvm.org/D67066. Consider
-mcmodel= unsupported for Sparc.
* https://reviews.llvm.org/D106371 translated -mcmodel=medium to
-mcmodel=large on AIX, even for 32-bit systems. Retain this behavior but
reject -mcmodel= for other PPC32 systems.
In general the accept/reject behavior is more similar to GCC.
err_drv_invalid_argument_to_option is less clear than
err_drv_unsupported_option_argument. As the supported values are
different for
different architectures, add a
err_drv_unsupported_option_argument_for_target
for better clarity.
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
Correct the logic used to set `ATOMIC_*_LOCK_FREE` preprocessor macros not
to rely on the ABI alignment of types. Instead, just assume all those
types are aligned correctly by default since clang uses safe alignment
for `_Atomic` types even if the underlying types are aligned to a lower
boundary by default.
For example, the `long long` and `double` types on x86 are aligned to
32-bit boundary by default. However, `_Atomic long long` and `_Atomic
double` are aligned to 64-bit boundary, therefore satisfying
the requirements of lock-free atomic operations.
This fixes PR #19355 by correcting the value of
`__GCC_ATOMIC_LLONG_LOCK_FREE` on x86, and therefore also fixing
the assumption made in libc++ tests. This also fixes PR #30581 by
applying a consistent logic between the functions used to implement
both interfaces.
Reviewed By: hfinkel, efriedma
Differential Revision: https://reviews.llvm.org/D28213
The intent of this patch is to add support of -fp-model=[source|double|extended] to allow
the compiler to use a wider type for intermediate floating point calculations. As a side
effect to that, the value of FLT_EVAL_METHOD is changed according to the pragma
float_control.
Unfortunately some issue was uncovered with this change in preprocessing. See details in
https://reviews.llvm.org/D93769 . We are therefore reverting this patch until we find a way
to reconcile the value of FLT_EVAL_METHOD, the pragma and the -E flow.
This reverts commit 66ddac22e2a7f268e91c26d694112970dfa607ae.
The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes the compiler to use a wider type for intermediate floating point
calculations. Also supported is a way to embed this effect in the source
program with #pragma float_control(source|double|extended).
This patch extends pragma float_control syntax, and also adds support
for a new floating point option "-ffp-eval-method=(source|double|extended)".
source: intermediate results use source precision
double: intermediate results use double precision
extended: intermediate results use extended precision
Reviewed By: Aaron Ballman
Differential Revision: https://reviews.llvm.org/D93769
The Intel compiler ICC supports the option "-fp-model=(source|double|extended)"
which causes the compiler to use a wider type for intermediate floating point
calculations. Also supported is a way to embed this effect in the source
program with #pragma float_control(source|double|extended).
This patch extends pragma float_control syntax, and also adds support
for a new floating point option "-ffp-eval-method=(source|double|extended)".
source: intermediate results use source precision
double: intermediate results use double precision
extended: intermediate results use extended precision
Reviewed By: Aaron Ballman
Differential Revision: https://reviews.llvm.org/D93769
Adds the __clang_literal_encoding__ and __clang_wide_literal_encoding__
predefined macros to expose the encoding used for string literals to
the preprocessor.
Some parts of the test had been extracted into separate files previously.
This patch continues the trend and extracts few more large blocks.
This reduces wall time for the test from a single 14s-long test into a set of
smaller tests that can be run in parallel.
Before/after state of the check-clang tests are here:
https://gist.github.com/Artem-B/d0b05c2e98a49158c02de23f7f4f0279
Differential Revision: https://reviews.llvm.org/D85798
