Summary:
The validity of ABI/CPU pairs is no longer checked on the fly but is
instead checked after initialization. As a result, invalid CPU/ABI pairs
can be reported as being known but invalid instead of being unknown. For
example, we now emit:
error: ABI 'n32' is not supported on CPU 'mips32r2'
instead of:
error: unknown target ABI 'n64'
Reviewers: atanasyan
Subscribers: sdardis, cfe-commits
Differential Revision: http://reviews.llvm.org/D21023
llvm-svn: 272645
Summary:
32-bit CPU's default to O32. 64-bit CPU's default to N64. The default CPU
(mips32r2/mips64r2) still depends on the arch so there's no functional
change when the CPU isn't specified but commands like:
clang -target mips-mti-linux-gnu -mips64r2
will now default to a 64-bit ABI like our gcc toolchains do* instead of
asserting in the backend**.
Other vendors (including Triple::UnknownVendor) still derive the default
ABI from the arch.
* Although not the same one as our gcc toolchains, clang has historically
defaulted to N64 where gcc defaults to N32.
** Mixing O32 and a 64-bit CPU causing assertions is a long-standing bug.
Reviewers: atanasyan
Subscribers: sdardis, cfe-commits
Differential Revision: http://reviews.llvm.org/D21016
llvm-svn: 271884
Summary:
There are no llvm backend tests* for EABI and no EABI buildbots. There were only
three clang tests, all of which checked that -mabi=eabi was passed to the
assembler.
*There is a single backend test that specifies EABI but it actually tests MIPS16.
Reviewers: atanasyan
Subscribers: emaste, sdardis, atanasyan, cfe-commits
Differential Revision: http://reviews.llvm.org/D20679
llvm-svn: 270998
Daniel Sanders