Disable _Float16 for non ARM/SPIR Targets

[erichkeane]

Summary

As Discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129543.html

There are problems exposing the _Float16 type on architectures that
haven't defined the ABI/ISel for the type yet, so we're temporarily
disabling the type and making it opt-in.

[rjmccall]

docs/LanguageExtensions.rst

497 ↗

(On Diff #183391)

This entire documentation section really just needs to be reworked. Here's a starting point:

Clang supports two half-precision (16-bit) floating point types: ``__fp16`` and
``_Float16``.  These types are supported in all language modes.

``__fp16`` is supported on every target, as it is purely a storage format; see below.
``_Float16`` is currently only supported on the following targets:
- 32-bit ARM
- 64-bit ARM (AArch64)
- SPIR
``_Float16`` will be supported on more targets as they define ABIs for them.

``__fp16`` is a storage and interchange format only.  This means that values of
``__fp16`` are immediately promoted to (at least) ``float`` when used in arithmetic
operations, so that e.g. the result of adding two ``__fp16`` values has type ``float``.
The behavior of ``__fp16`` is specified by the ARM C Language Extensions (`ACLE <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053d/IHI0053D_acle_2_1.pdf>`_).
Clang uses the ``binary16`` format from IEEE 754-2008 for ``__fp16``, not the ARM
alternative format.

``_Float16`` is an extended floating-point type.  This means that, just like arithmetic on
``float`` or ``double``, arithmetic on ``_Float16`` operands is formally performed in the
``_Float16`` type, so that e.g. the result of adding two ``_Float16`` values has type
``_Float16``.  The behavior of ``_Float16`` is specified by ISO/IEC TS 18661-3:2015
("Floating-point extensions for C").  As with ``__fp16``, Clang uses the ``binary16``
format from IEEE 754-2008 for ``_Float16``.

``_Float16`` arithmetic will be performed using native half-precision support
when available on the target (e.g. on ARMv8.2a); otherwise it will be performed
at a higher precision (currently always ``float``) and then truncated down to
``_Float16``.  Note that C and C++ allow intermediate floating-point operands
of an expression to be computed with greater precision than is expressible in
their type, so Clang may avoid intermediate truncations in certain cases; this may
lead to results that are inconsistent with native arithmetic.

It is recommended that portable code use ``_Float16`` instead of ``__fp16``,
as it has been defined by the C standards committee and has behavior that is
more familiar to most programmers.

Because ``__fp16`` operands are always immediately promoted to ``float``, the
common real type of ``__fp16`` and ``_Float16`` for the purposes of the usual
arithmetic conversions is ``float``.

A literal can be given ``_Float16`` type using the suffix ``f16``; for example:
```
  3.14f16
```

Because default argument promotion only applies to the standard floating-point
types, ``_Float16`` values are not promoted to ``double`` when passed as variadic
or untyped arguments.  As a consequence, some caution must be taken when using
certain library facilities with ``_Float16``; for example, there is no ``printf`` format
specifier for ``_Float16``, and (unlike ``float``) it will not be implicitly promoted to
``double`` when passed to ``printf``, so the programmer must explicitly cast it to
``double`` before using it with an ``%f`` or similar specifier.

lib/Basic/Targets/AArch64.cpp

52 ↗

(On Diff #183391)

spacing

lib/Basic/Targets/SPIR.h

50 ↗

(On Diff #183391)

spacing

[SjoerdMeijer]

include/clang/Basic/TargetInfo.h

66 ↗

(On Diff #183391)

I think this is the same as HasLegalHalfType, and we can (re)use that. Or, at least, don't think we need both HasLegalHalfType and HasFloat16. For context, I needed HasLegalHalfType for argument passing, but it looks like it can serve another purpose now.

Out of curiousity, I was wondering if specifying:

KEYWORD(_Float16                    , HALFSUPPORT)

in TokenKids.def is an alternative approach (it is currently set to KEYALL). Thus, enable the keyword when LangOpts.Half is set. By adding this HasFloat16 property here in clang's targetinfo, we're sort of defining again how targets support different types. I.e., if you throw a half type at the backend, the TypeLegalizer will deal with it in one way or another. Perhaps disabling _Float16 can be achieved by disabling the keyword. But I do see that the big advantage of this patch is the much nicer error message (otherwise we would get something like "unknown type name '_Float16'").

521 ↗

(On Diff #183391)

Similar remark: the same as hasLegalHalfType()?

[erichkeane]

include/clang/Basic/TargetInfo.h

66 ↗

(On Diff #183391)

LangOpts.Half (and thus HALFSUPPORT) seems to be specific to OpenCL. It seems to me that the two ARE different, the Half type and the _Float16 type are different semantically and from different standards, so I think that isn't sufficient.

Additionally, from a diagnostics perspective I think it is worse to do it in the TokenKinds.def. If you do it in TokenKinds.def, you get "Type Expected" or "Unknown Type Name", which could encourage someone to write their own. The error message in this patch (Not supported on this target) strongly states that it is a reserved word and is not to be defined. This is particularly important for the targets that intend to add support for this in the future.

Additionally, HasLegalHalfType has slightly different semantics in the ARM case. ARM seems to still want _Float16 to work even without the +fullfp16 support. It seems to be OK (based on CodeGen and the tests written to validate this) with allowing the _Float16 support to work with different code generation.

[rjmccall]

This LGTM with one minor revision; feel free to commit with that.

For follow-up commit consideration: @scanon, do we want to support _Float16 anywhere else? Do we need to lock down an ABI here for i386/x86_64 in advance of those gears turning in the outer world?

docs/LanguageExtensions.rst

484 ↗

(On Diff #183536)

"them" should be "it" here.

497 ↗

(On Diff #183391)

Hmm. Here's a better way of expressing part of that:

``_Float16`` is currently only supported on the following targets, with further
targets pending ABI standardization:
- 32-bit ARM
- 64-bit ARM (AArch64)
- SPIR

[scanon]

do we want to support _Float16 anywhere else?

ARM is the only in-tree target with a defined ABI that I'm aware of.

Do we need to lock down an ABI here for i386/x86_64 in advance of those gears turning in the outer world?

We definitely want to push for one to be defined (and make sure that it makes sense), but I don't think we don't need to rush ahead of everyone, rather get to preliminary agreement. I think @ab was going to follow-up on that?

[rjmccall]

docs/LanguageExtensions.rst

484 ↗

(On Diff #183536)

Sorry, apparently Phabricator was sitting on a comment I made yesterday; ignore it, please, and just go with s/them/it/.

[rjmccall]

"it" is the grammatically correct word.

[yaxunl]

This change causes regressions for CUDA/HIP. As single-source language, CUDA/HIP code contains both device and host code. It has separate compilation for host and device.
In host compilation, device function is parsed but not emitted in IR. The device function may have _Float16 argument, which is fine if device target supports it. Host compilation
should not diagnose use of _Float16 in device functions. However, current implementation diagnose any _Float16 usage in host compilation.

[rjmccall]

In D57188#1374890, @yaxunl wrote:

This change causes regressions for CUDA/HIP. As single-source language, CUDA/HIP code contains both device and host code. It has separate compilation for host and device.
In host compilation, device function is parsed but not emitted in IR. The device function may have _Float16 argument, which is fine if device target supports it. Host compilation
should not diagnose use of _Float16 in device functions. However, current implementation diagnose any _Float16 usage in host compilation.

Can this be reasonably delayed using the existing diagnostic-delay mechanism, or is there a problem where the diagnostics aren't necessarily bound to a function definition?

[rjmccall]

Regardless, I think it would be fine if you wanted to add a CUDA/HIP exception to this check in the short term.

cfe/trunk/docs/LanguageExtensions.rst

 ============================== ======= ======= ======= =======
 
 See also :ref:`langext-__builtin_shufflevector`, :ref:`langext-__builtin_convertvector`.
 
 Half-Precision Floating Point
 =============================
 
 Clang supports two half-precision (16-bit) floating point types: ``__fp16`` and
-``_Float16``. ``__fp16`` is defined in the ARM C Language Extensions (`ACLE
-<http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053d/IHI0053D_acle_2_1.pdf>`_)
-and ``_Float16`` in ISO/IEC TS 18661-3:2015.
+``_Float16``.  These types are supported in all language modes.
+
+``__fp16`` is supported on every target, as it is purely a storage format; see below.
+``_Float16`` is currently only supported on the following targets, with further
+targets pending ABI standardization:
+- 32-bit ARM
+- 64-bit ARM (AArch64)
+- SPIR
+``_Float16`` will be supported on more targets as they define ABIs for it.
 
-``__fp16`` is a storage and interchange format only. This means that values of
-``__fp16`` promote to (at least) float when used in arithmetic operations.
-There are two ``__fp16`` formats. Clang supports the IEEE 754-2008 format and
-not the ARM alternative format.
-
-ISO/IEC TS 18661-3:2015 defines C support for additional floating point types.
-``_FloatN`` is defined as a binary floating type, where the N suffix denotes
-the number of bits and is 16, 32, 64, or greater and equal to 128 and a
-multiple of 32. Clang supports ``_Float16``. The difference from ``__fp16`` is
-that arithmetic on ``_Float16`` is performed in half-precision, thus it is not
-a storage-only format. ``_Float16`` is available as a source language type in
-both C and C++ mode.
-
-It is recommended that portable code use the ``_Float16`` type because
-``__fp16`` is an ARM C-Language Extension (ACLE), whereas ``_Float16`` is
-defined by the C standards committee, so using ``_Float16`` will not prevent
-code from being ported to architectures other than Arm.  Also, ``_Float16``
-arithmetic and operations will directly map on half-precision instructions when
-they are available (e.g. Armv8.2-A), avoiding conversions to/from
-single-precision, and thus will result in more performant code. If
-half-precision instructions are unavailable, values will be promoted to
-single-precision, similar to the semantics of ``__fp16`` except that the
-results will be stored in single-precision.
-
-In an arithmetic operation where one operand is of ``__fp16`` type and the
-other is of ``_Float16`` type, the ``_Float16`` type is first converted to
-``__fp16`` type and then the operation is completed as if both operands were of
-``__fp16`` type.
-
-To define a ``_Float16`` literal, suffix ``f16`` can be appended to the compile-time
-constant declaration. There is no default argument promotion for ``_Float16``; this
-applies to the standard floating types only. As a consequence, for example, an
-explicit cast is required for printing a ``_Float16`` value (there is no string
-format specifier for ``_Float16``).
+``__fp16`` is a storage and interchange format only.  This means that values of
+``__fp16`` are immediately promoted to (at least) ``float`` when used in arithmetic
+operations, so that e.g. the result of adding two ``__fp16`` values has type ``float``.
+The behavior of ``__fp16`` is specified by the ARM C Language Extensions (`ACLE <http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053d/IHI0053D_acle_2_1.pdf>`_).
+Clang uses the ``binary16`` format from IEEE 754-2008 for ``__fp16``, not the ARM
+alternative format.
+
+``_Float16`` is an extended floating-point type.  This means that, just like arithmetic on
+``float`` or ``double``, arithmetic on ``_Float16`` operands is formally performed in the
+``_Float16`` type, so that e.g. the result of adding two ``_Float16`` values has type
+``_Float16``.  The behavior of ``_Float16`` is specified by ISO/IEC TS 18661-3:2015
+("Floating-point extensions for C").  As with ``__fp16``, Clang uses the ``binary16``
+format from IEEE 754-2008 for ``_Float16``.
+
+``_Float16`` arithmetic will be performed using native half-precision support
+when available on the target (e.g. on ARMv8.2a); otherwise it will be performed
+at a higher precision (currently always ``float``) and then truncated down to
+``_Float16``.  Note that C and C++ allow intermediate floating-point operands
+of an expression to be computed with greater precision than is expressible in
+their type, so Clang may avoid intermediate truncations in certain cases; this may
+lead to results that are inconsistent with native arithmetic.
+
+It is recommended that portable code use ``_Float16`` instead of ``__fp16``,
+as it has been defined by the C standards committee and has behavior that is
+more familiar to most programmers.
+
+Because ``__fp16`` operands are always immediately promoted to ``float``, the
+common real type of ``__fp16`` and ``_Float16`` for the purposes of the usual
+arithmetic conversions is ``float``.
+
+A literal can be given ``_Float16`` type using the suffix ``f16``; for example:
+```
+  3.14f16
+  ```
+
+Because default argument promotion only applies to the standard floating-point
+types, ``_Float16`` values are not promoted to ``double`` when passed as variadic
+or untyped arguments.  As a consequence, some caution must be taken when using
+certain library facilities with ``_Float16``; for example, there is no ``printf`` format
+specifier for ``_Float16``, and (unlike ``float``) it will not be implicitly promoted to
+``double`` when passed to ``printf``, so the programmer must explicitly cast it to
+``double`` before using it with an ``%f`` or similar specifier.
 
 Messages on ``deprecated`` and ``unavailable`` Attributes
 =========================================================
 
 An optional string message can be added to the ``deprecated`` and
 ``unavailable`` attributes.  For example:
 
 .. code-block:: c++

cfe/trunk/include/clang/Basic/TargetInfo.h

protected:
   // values are specified by the TargetInfo constructor.
   bool BigEndian;
   bool TLSSupported;
   bool VLASupported;
   bool NoAsmVariants;  // True if {|} are normal characters.
   bool HasLegalHalfType; // True if the backend supports operations on the half
                          // LLVM IR type.
   bool HasFloat128;
+  bool HasFloat16;
   unsigned char PointerWidth, PointerAlign;
   unsigned char BoolWidth, BoolAlign;
   unsigned char IntWidth, IntAlign;
   unsigned char HalfWidth, HalfAlign;
   unsigned char FloatWidth, FloatAlign;
   unsigned char DoubleWidth, DoubleAlign;
   unsigned char LongDoubleWidth, LongDoubleAlign, Float128Align;
   unsigned char LargeArrayMinWidth, LargeArrayAlign;
public:
   } // FIXME
 
   /// Determine whether _Float16 is supported on this target.
   virtual bool hasLegalHalfType() const { return HasLegalHalfType; }
 
   /// Determine whether the __float128 type is supported on this target.
   virtual bool hasFloat128Type() const { return HasFloat128; }
 
+  /// Determine whether the _Float16 type is supported on this target.
+  virtual bool hasFloat16Type() const { return HasFloat16; }
+
   /// Return the alignment that is suitable for storing any
   /// object with a fundamental alignment requirement.
   unsigned getSuitableAlign() const { return SuitableAlign; }
 
   /// Return the default alignment for __attribute__((aligned)) on
   /// this target, to be used if no alignment value is specified.
   unsigned getDefaultAlignForAttributeAligned() const {
     return DefaultAlignForAttributeAligned;

cfe/trunk/lib/Basic/TargetInfo.cpp

TargetInfo::TargetInfo(const llvm::Triple &T) : TargetOpts(), Triple(T) {
   // Set defaults.  Defaults are set for a 32-bit RISC platform, like PPC or
   // SPARC.  These should be overridden by concrete targets as needed.
   BigEndian = !T.isLittleEndian();
   TLSSupported = true;
   VLASupported = true;
   NoAsmVariants = false;
   HasLegalHalfType = false;
   HasFloat128 = false;
+  HasFloat16 = false;
   PointerWidth = PointerAlign = 32;
   BoolWidth = BoolAlign = 8;
   IntWidth = IntAlign = 32;
   LongWidth = LongAlign = 32;
   LongLongWidth = LongLongAlign = 64;
 
   // Fixed point default bit widths
   ShortAccumWidth = ShortAccumAlign = 16;

cfe/trunk/lib/Basic/Targets/AArch64.cpp

if (!getTriple().isOSDarwin() && !getTriple().isOSNetBSD())
       WCharType = UnsignedInt;
 
     Int64Type = SignedLong;
     IntMaxType = SignedLong;
   }
 
   // All AArch64 implementations support ARMv8 FP, which makes half a legal type.
   HasLegalHalfType = true;
+  HasFloat16 = true;
 
   LongWidth = LongAlign = PointerWidth = PointerAlign = 64;
   MaxVectorAlign = 128;
   MaxAtomicInlineWidth = 128;
   MaxAtomicPromoteWidth = 128;
 
   LongDoubleWidth = LongDoubleAlign = SuitableAlign = 128;
   LongDoubleFormat = &llvm::APFloat::IEEEquad();

cfe/trunk/lib/Basic/Targets/ARM.cpp

bool ARMTargetInfo::handleTargetFeatures(std::vector<std::string> &Features,
   FPU = 0;
   CRC = 0;
   Crypto = 0;
   DSP = 0;
   Unaligned = 1;
   SoftFloat = SoftFloatABI = false;
   HWDiv = 0;
   DotProd = 0;
+  HasFloat16 = true;
 
   // This does not diagnose illegal cases like having both
   // "+vfpv2" and "+vfpv3" or having "+neon" and "+fp-only-sp".
   uint32_t HW_FP_remove = 0;
   for (const auto &Feature : Features) {
     if (Feature == "+soft-float") {
       SoftFloat = true;
     } else if (Feature == "+soft-float-abi") {

cfe/trunk/lib/Basic/Targets/SPIR.h

SPIRTargetInfo(const llvm::Triple &Triple, const TargetOptions &)
     assert(getTriple().getEnvironment() == llvm::Triple::UnknownEnvironment &&
            "SPIR target must use unknown environment type");
     TLSSupported = false;
     VLASupported = false;
     LongWidth = LongAlign = 64;
     AddrSpaceMap = &SPIRAddrSpaceMap;
     UseAddrSpaceMapMangling = true;
     HasLegalHalfType = true;
+    HasFloat16 = true;
     // Define available target features
     // These must be defined in sorted order!
     NoAsmVariants = true;
   }
 
   void getTargetDefines(const LangOptions &Opts,
                         MacroBuilder &Builder) const override;
 

cfe/trunk/lib/Sema/SemaType.cpp

case DeclSpec::TST_int128:
     if (!S.Context.getTargetInfo().hasInt128Type())
       S.Diag(DS.getTypeSpecTypeLoc(), diag::err_type_unsupported)
         << "__int128";
     if (DS.getTypeSpecSign() == DeclSpec::TSS_unsigned)
       Result = Context.UnsignedInt128Ty;
     else
       Result = Context.Int128Ty;
     break;
-  case DeclSpec::TST_float16: Result = Context.Float16Ty; break;
+  case DeclSpec::TST_float16:
+    if (!S.Context.getTargetInfo().hasFloat16Type())
+      S.Diag(DS.getTypeSpecTypeLoc(), diag::err_type_unsupported)
+        << "_Float16";
+    Result = Context.Float16Ty;
+    break;
   case DeclSpec::TST_half:    Result = Context.HalfTy; break;
   case DeclSpec::TST_float:   Result = Context.FloatTy; break;
   case DeclSpec::TST_double:
     if (DS.getTypeSpecWidth() == DeclSpec::TSW_long)
       Result = Context.LongDoubleTy;
     else
       Result = Context.DoubleTy;
     break;

cfe/trunk/test/AST/float16.cpp

-// RUN: %clang_cc1 -std=c++11 -ast-dump %s | FileCheck %s --strict-whitespace
-// RUN: %clang_cc1 -std=c++11 -ast-dump -fnative-half-type %s | FileCheck %s --check-prefix=CHECK-NATIVE --strict-whitespace
+// RUN: %clang_cc1 -std=c++11 -ast-dump -triple aarch64-linux-gnu %s | FileCheck %s --strict-whitespace
+// RUN: %clang_cc1 -std=c++11 -ast-dump -triple aarch64-linux-gnu -fnative-half-type %s | FileCheck %s --check-prefix=CHECK-NATIVE --strict-whitespace
 
 /*  Various contexts where type _Float16 can appear. */
 
 /*  Namespace */
 namespace {
   _Float16 f1n;
   _Float16 f2n = 33.f16;
   _Float16 arr1n[10];

cfe/trunk/test/CodeGenCXX/float16-declarations.cpp

 // RUN: %clang -std=c++11 --target=aarch64-arm--eabi -S -emit-llvm %s -o - | FileCheck %s  --check-prefix=CHECK --check-prefix=CHECK-AARCH64
-// RUN: %clang -std=c++11 --target=x86_64 -S -emit-llvm %s -o - | FileCheck %s  --check-prefix=CHECK --check-prefix=CHECK-X86
 
 /*  Various contexts where type _Float16 can appear. */
 
 
 /*  Namespace */
 
 namespace {
   _Float16 f1n;
 // CHECK-DAG: @_ZN12_GLOBAL__N_13f1nE = internal global half 0xH0000, align 2
 
   _Float16 f2n = 33.f16;
 // CHECK-DAG: @_ZN12_GLOBAL__N_13f2nE = internal global half 0xH5020, align 2
 
   _Float16 arr1n[10];
 // CHECK-AARCH64-DAG: @_ZN12_GLOBAL__N_15arr1nE = internal global [10 x half] zeroinitializer, align 2
-// CHECK-X86-DAG:     @_ZN12_GLOBAL__N_15arr1nE = internal global [10 x half] zeroinitializer, align 16
 
   _Float16 arr2n[] = { 1.2, 3.0, 3.e4 };
 // CHECK-DAG: @_ZN12_GLOBAL__N_15arr2nE = internal global [3 x half] [half 0xH3CCD, half 0xH4200, half 0xH7753], align 2
 
   const volatile _Float16 func1n(const _Float16 &arg) {
     return arg + f2n + arr1n[4] - arr2n[1];
   }
 }
 
 
 /* File */
 
 _Float16 f1f;
 // CHECK-AARCH64-DAG: @f1f = dso_local global half 0xH0000, align 2
-// CHECK-X86-DAG: @f1f = dso_local global half 0xH0000, align 2
 
 _Float16 f2f = 32.4;
 // CHECK-DAG: @f2f = dso_local global half 0xH500D, align 2
 
 _Float16 arr1f[10];
 // CHECK-AARCH64-DAG: @arr1f = dso_local global [10 x half] zeroinitializer, align 2
-// CHECK-X86-DAG: @arr1f = dso_local global [10 x half] zeroinitializer, align 16
 
 _Float16 arr2f[] = { -1.2, -3.0, -3.e4 };
 // CHECK-DAG: @arr2f = dso_local global [3 x half] [half 0xHBCCD, half 0xHC200, half 0xHF753], align 2
 
 _Float16 func1f(_Float16 arg);
 
 
 /* Class */
//CHECK-DAG:  store float [[H2F]], float* %{{.*}}, align 4
   double cvtd = f2n;
 //CHECK-DAG: [[H2D:%[a-z0-9]+]] = fpext half {{%[0-9]+}} to double
 //CHECK-DAG: store double [[H2D]], double* %{{.*}}, align 8
 
 
   long double cvtld = f2n;
 //CHECK-AARCh64-DAG: [[H2LD:%[a-z0-9]+]] = fpext half {{%[0-9]+}} to fp128
 //CHECK-AARCh64-DAG: store fp128 [[H2LD]], fp128* %{{.*}}, align 16
-//CHECK-X86-DAG:     [[H2LD:%[a-z0-9]+]] = fpext half {{%[0-9]+}} to x86_fp80
-//CHECK-X86-DAG:     store x86_fp80 [[H2LD]], x86_fp80* %{{.*}}, align 16
 
   _Float16 f2h = 42.0f;
 //CHECK-DAG: store half 0xH5140, half* %{{.*}}, align 2
   _Float16 d2h = 42.0;
 //CHECK-DAG: store half 0xH5140, half* %{{.*}}, align 2
   _Float16 ld2h = 42.0l;
 //CHECK-DAG:store half 0xH5140, half* %{{.*}}, align 2
 }

cfe/trunk/test/CodeGenCXX/mangle-ms.cpp

 // RUN: %clang_cc1 -fblocks -emit-llvm %s -o - -triple=i386-pc-win32 -std=c++98 | FileCheck %s
 // RUN: %clang_cc1 -fblocks -emit-llvm %s -o - -triple=x86_64-pc-win32 -std=c++98| FileCheck -check-prefix X64 %s
+// RUN: %clang_cc1 -fblocks -emit-llvm %s -o - -triple=aarch64-pc-win32 -std=c++98 -DARM | FileCheck -check-prefixes=X64,ARM %s
 
 int a;
 // CHECK-DAG: @"?a@@3HA"
 
 extern "C++" {
 static int __attribute__((used)) ignore_transparent_context;
 // CHECK-DAG: @ignore_transparent_context
 }

 namespace Atomic {
 // CHECK-DAG: define dso_local void @"?f@Atomic@@YAXU?$_Atomic@H@__clang@@@Z"(
 void f(_Atomic(int)) {}
 }
 namespace Complex {
 // CHECK-DAG: define dso_local void @"?f@Complex@@YAXU?$_Complex@H@__clang@@@Z"(
 void f(_Complex int) {}
 }
+#ifdef ARM
 namespace Float16 {
-// CHECK-DAG: define dso_local void @"?f@Float16@@YAXU_Float16@__clang@@@Z"(
+// ARM-DAG: define dso_local void @"?f@Float16@@YAXU_Float16@__clang@@@Z"(
 void f(_Float16) {}
 }
+#endif // ARM
 
 namespace PR26029 {
 template <class>
 struct L {
   L() {}
 };
 template <class>
 class H;

cfe/trunk/test/Lexer/half-literal.cpp

-// RUN: %clang_cc1 -fsyntax-only -verify -pedantic %s
+// RUN: %clang_cc1 -fsyntax-only -verify -pedantic -triple aarch64-linux-gnu %s
 float a = 1.0h; // expected-error{{no matching literal operator for call to 'operator""h' with argument of type 'long double' or 'const char *', and no matching literal operator template}}
 float b = 1.0H; // expected-error{{invalid suffix 'H' on floating constant}}
 
 _Float16 c = 1.f166; // expected-error{{invalid suffix 'f166' on floating constant}}
 _Float16 d = 1.f1;   // expected-error{{invalid suffix 'f1' on floating constant}}

cfe/trunk/test/Sema/Float16.c

+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+
+#ifdef HAVE
+// expected-no-diagnostics
+#else
+// expected-error@+2{{_Float16 is not supported on this target}}
+#endif // HAVE
+_Float16 f;