We make the same decision when compiling the kernel or kexts -- we
should do this in -ffreestanding mode as well to avoid size regressions
in a potentially large set of firmware projects.
It's still possible to get uwtable information in -ffreestanding mode by
compiling with -funwind-tables (I expect this to be a rare case: I
certainly haven't seen any projects like that).
Context: -munwind-tables was enabled by default for some arm targets in
r310006.
Testing: check-clang
rdar://problem/33934446
Differential Revision: https://reviews.llvm.org/D37777
llvm-svn: 313087
supplied.
With this change, -fno-exceptions disables unwind tables unless
-funwind-tables is supplied too or the target is x86-64 (x86-64 requires
emitting unwind tables).
rdar://problem/33934446
llvm-svn: 311397
This commit fixes a bug where clang/llvm doesn't emit an unwind table
for a function when it is marked noexcept. Without this patch, the
following code terminates with an uncaught exception on ARM64:
int foo1() noexcept {
try {
throw 0;
} catch (int i) {
return 0;
}
return 1;
}
int main() {
return foo1();
}
rdar://problem/32411865
Differential Revision: https://reviews.llvm.org/D35693
llvm-svn: 310006
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
Teach the '-arch' command line option to enable the compiler-friendly
features of core-avx2 CPUs on Darwin. Pass the information along in the
target triple like Darwin+ARM does.
llvm-svn: 194907
clang itself. This dates back to clang's early days and while it looks like
some of it is still used (for kext for example), other parts are probably dead.
Remove the -ccc-clang-archs option and associated code. I don't think there
is any remaining setup where clang doesn't support an architecture but it can
expect an working gcc cross compiler to be available.
A nice side effect is that tests no longer need to differentiate architectures
that are included in production builds of clang and those that are not.
llvm-svn: 165545
The darwin change should be a nop since Triple::getArchTypeForDarwinArchName
doesn't know about amd64.
If things like amd64-mingw32 are to be rejected, we should print a error
earlier on instead of silently using the wrong abi.
Remove old comment that looks out of place, this is "in clang".
llvm-svn: 165368
This functionality is based on what is done on ARM, and enables selecting PPC CPUs
in a way compatible with gcc's driver. Also, mirroring gcc (and what is done on x86),
-mcpu=native support was added. This uses the host cpu detection from LLVM
(which will also soon be updated by refactoring code currently in backend).
In order for this to work, the target needs a list of valid CPUs -- we now accept all CPUs accepted by LLVM.
A few preprocessor defines for common CPU types have been added.
llvm-svn: 158334
- We still need support for detecting the target features, since the name
doesn't actually do a good job of decribing what the CPU supports (for LLVM).
llvm-svn: 88819
Vedant Kumar