[X86][clang] Disable long double type for -mno-x87 option

[asavonic]

Summary

This patch attempts to fix a compiler crash that occurs when long double type
is used with -mno-x87 compiler option.

The option disables x87 target feature, which in turn disables x87 registers, so
CG cannot select them for x86_fp80 LLVM IR type. Long double is lowered as
x86_fp80 for some targets, so it leads to a crash.

The option seems to contradict the SystemV ABI, which requires long double to
be represented as a 80-bit floating point, and it also requires to use x87 registers.

In addition to that, float and double also use x87 registers for
return values on 32-bit x86, so they are disabled as well.

[asavonic]

I'm not sure that this is the right approach, but I wanted to get feedback on
how the issue should be fixed. Currently, the compiler crashes on almost any
code with long double and -mno-x87 (excluding cases where CG does not properly disable x87):

long double foo(long double x, long double y)
{
  long double z = x + y;
  if (z < 0.0)
    return z;
  else
    return 0.0;
}

[asavonic]

The option was added in D19658 and D13979, but I'm not sure how it is supposed to work for SystemV ABI.
GCC emits an error if long double type is used with -mno-x87: "test.c:37:1: error: x87 register return with x87 disabled".

Added reviewers of the original patches. Please let me know if this patch makes sense, or we should do something else to avoid the crash.

[asavonic]

ping

[pengfei]

clang/test/Sema/x86-no-x87.c

48–61

These seems pass with GCC. https://godbolt.org/z/qM4nWhThx

[asavonic]

clang/test/Sema/x86-no-x87.c

48–61

Right. Assignment of a literal is compiled to just mov without any x87 instructions, so it is not diagnosed by GCC. On the other hand, assignment of a variable does trigger the error:

void assign4(double d) {
  struct st_long_double st;
  st.ld = d; // error: long double is not supported on this target
}

We can update the patch to do the same for some cases, but it does not look very consistent, and makes assumptions on how the code is optimized and compiled.

GCC has an advantage here, because it emits the diagnostic at a lower level after at lease some optimizations are done. For example, the following code does not trigger an error for GCC because of inlining:

double get_const() {
  return 0.42;
}
void assign5(struct st_long_double *st) {
  st->ld = get_const();
}

[pengfei]

clang/test/Sema/x86-no-x87.c

48–61

I see. Another concern is about the 32 bits. @LiuChen3 had tested in D100091 that GCC doesn't error for 32 bits. Do we need to consider it here?

[asavonic]

clang/test/Sema/x86-no-x87.c

48–61

Yes, it should be considered. Both x86 and x86_64 SysV ABI targets require x87 to be used for long double. Other targets have different requirements for long double: double precision for Windows, double and quad precision for Android x86 and x86_64 respectively.

[asavonic]

Added LIT run lines for i686 and windows targets.

[pengfei]

clang/test/Sema/x86-no-x87.c

3

Should i686 expect no error like GCC?

[asavonic]

clang/test/Sema/x86-no-x87.c

3

GCC seems to fallback to soft-float for i686 if -mno-80387 is used:

long double orig(long double x, long double y)
{
  long double z = x + y;
  if (z < 0.0)
    return z;
  else
    return 0.0;
}

i686-linux-gnu-gcc-8 -c -S -mno-80387 -O3:

	  call	__addxf3@PLT
	  [...]
	  call	__ltxf2@PLT
	  addl	$32, %esp
	  testl	%eax, %eax
	  js	.L3
	  xorl	%esi, %esi
	  xorl	%edi, %edi
	  xorl	%ebp, %ebp
  .L3:
	  addl	$12, %esp
	  movl	%esi, %eax
	  movl	%edi, %edx
	  movl	%ebp, %ecx
	  popl	%ebx
	  popl	%esi
	  popl	%edi
	  popl	%ebp
	  ret

This looks like a different ABI.
X87 instructions are not used, so no error is reported.

[pengfei]

clang/test/Sema/x86-no-x87.c

3

I found it's a bit complex for 32 bits.

1. i686 ABI specifies the return of floating point type must be put in %st0, so any FP type returning should be error out w/o x87.
2. GCC doesn't respect above ABI.
3. FP types are passed from stack, so a function like void orig(long double x, long double y, long double *z) should not be error out w/o x87.

x86_64 only uses ST registers when returning FP80.
Considering it is rare for case 3, I think we can ignore it this time, but I suggest we should add check for float and double on 32 bits.

[asavonic]

• Disabled double or float return for x86 targets
• Refactored checks into a separate function.

[pengfei]

LGTM. But let's wait one or more days to see if others have more comments.

clang/lib/Sema/SemaChecking.cpp

4602

Nit: We can save the curly bracket for it.

14022

ditto

[asavonic]

@erichkeane, can you please check if this patch is OK for Clang?

[erichkeane]

This seems to do a lot of work that I think already exists, I believe I've seen that SPIRV targets already prohibit long-double, so doing another implementation specifically for x86 seems like the wrong approach. I'd suggest seeing if the SPIRV version works for these. If it doesn't, I'd prefer you generalize that implementation.

clang/include/clang/Basic/TargetInfo.h

588

I think SPIR targets already do something like this, can you check and see how they do it instead?

[asavonic]

Thanks @erichkeane. SPIR-V diagnostics seem to work fine. There are a few cases that are not handled, so I submitted D109315 to review them separately.

[asavonic]

Rebased the patch on top of D109315.

Since the diagnostic is now shared with other targets (SYCL and
OpenMP), I decided to drop all assumptions on optimizations that
we previously discussed. There seems to be no actual use case
where it is important to have them (other than compatibility with
GCC), and they make rules a bit inconsistent.

[asavonic]

@pengfei, @erichkeane, please let me know if the patch is OK now, or anything else needs to be fixed.

[erichkeane]

@Fznamznon was into this a bunch at once, so she should probably take a look as well.

clang/lib/Sema/Sema.cpp

1936 ↗

(On Diff #381538)

Should this be a return, or do we still intend the device invocations to go through the below checks too?

If so, please write a test for that.

clang/lib/Sema/SemaDecl.cpp

9438–9439

Why are we not checking declarations here? This doesn't seem right to me. At least in the offload languages, we still need to check declarations. Also, if something is a problem with a declaration, why is it not a problem with defaulted/deleted?

[asavonic]

clang/lib/Sema/SemaDecl.cpp

9438–9439

Why are we not checking declarations here? This doesn't seem right to me. At least in the offload languages, we still need to check declarations.

I assume that if if a function is declared and not used, then it is discarded and no code is generated for it. So it should not really matter if it uses an "unsupported" type.
This is important for long double, because there are C standard library functions that have long double arguments. We skip diagnostics for declarations to avoid errors from standard library headers when the type is actually not used.

Also, if something is a problem with a declaration, why is it not a problem with defaulted/deleted?

If we can expect that defaulted or deleted functions never result in a code with unsupported types, then we can exclude them as well. Something like this perhaps?

void no_long_double(long double) = delete;

[erichkeane]

clang/lib/Sema/SemaDecl.cpp

9438–9439

The problem is that these declarations could be called, right? So are we catching something like:

 void has_long_double(long double d);
....
has_long_double(1.0);

The deleted types shouldn't result in code being generated, but default will absolutely result in code being generated. Though I guess I can't think of a situation where we would have a defaulted function that could take a long double anyway.

[asavonic]

clang/lib/Sema/SemaDecl.cpp

9438–9439

The problem is that these declarations could be called, right? So are we catching something like:

 void has_long_double(long double d);
....
has_long_double(1.0);

Yes, we catch this when the function is called (see below). This is done in Sema::DiagnoseUseOfDecl.

The deleted types shouldn't result in code being generated, but default will absolutely result in code being generated. Though I guess I can't think of a situation where we would have a defaulted function that could take a long double anyway.

Thank you. I'll update the patch to exclude deleted functions.

clang/test/Sema/x86-no-x87.c

36

This is the case where a declaration is called.

[asavonic]

clang/lib/Sema/Sema.cpp

1936 ↗

(On Diff #381538)

It should be fine either way. New diagnostics are disabled if TI.hasLongDoubleType and TI.hasFPReturn return "true", as expected for SYCL and OpenMP device targets.

Added a test for SYCL, OpenMP already has tests with long double type.

[asavonic]

• Added a test for SYCL.
• Excluded functions marked with C++ delete from the check.
• Moved the check function from ActOnFunctionDeclarator to ActOnFinishFunctionBody, because the deleted/defaulted property is not yet available in ActOnFunctionDeclarator.

[nickdesaulniers]

This seems to be causing build errors for the linux kernel (which uses -mno-x87) for expressions like: unsigned long foo = 300L * 1E6L;
https://github.com/ClangBuiltLinux/linux/issues/1497

// clang -O2 -mno-x87
void foo (unsigned long);
void bar (void) { foo(1 * 1E6L); }

<source>:3:25: error: expression requires  'long double' type support, but target 'x86_64-unknown-linux-gnu' does not support it
void bar (void) { foo(1 * 1E6L); }
                        ^

While we can change kernel sources to not use L suffixes for floating point literals, this is a curious difference from GCC and may lead to compatibility issues with other code bases.

[asavonic]

@nickdesaulniers, thanks a lot for reporting this!
Unfortunately it is not easy to keep compatibility with GCC in this case. GCC has this diagnostic very late in the pipeline, and trivial uses of long double type (e.g. unused variables, constant expressions) can be optimized away before that. We cannot do the same with LLVM, because there is no way to emit a nice source-level diagnostic from the codegen.
I suggest to fix the kernel, because it looks like the long double literal is not intentional and can be replaced with just double.

[eandrews]

This patch causes a regression.

To reproduce - clang -cc1 -fsycl-is-device -triple spir64 test.cpp

// expected-note@+2 {{'bar<__float128>' defined here}}
template <typename T>
T bar() { return T(); };

void usage() {
  // expected-error@+2 {{'bar<__float128>' requires 128 bit size '__float128' type support, but target 'spir64' does not support it}}
  // expected-error@+1 {{'__float128' is not supported on this target}}
  auto malAutoTemp5 = bar<__float128>();
}
template <typename name, typename Func>
__attribute__((sycl_kernel)) void kernel_single_task(const Func &kernelFunc) {
  kernelFunc(); // expected-note {{called by 'kernel_single_task<fake_kernel, (lambda at}}
}

int main() {
  kernel_single_task<class fake_kernel>([=]() {
    usage(); // expected-note {{called by 'operator()'}}
  });
  return 0;
}

This test now fails due to an additional diagnostic generated at template definition.

test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' type support, but target 'spir64' does not support it
T bar() { return T(); };
  ^

I looked at it briefly, and I believe the issue is call to checkTypeSupport() in ActOnFinishFunctionBody(). I tried deleting the call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please take a look. I will be reverting the patch if this cannot be fixed soon.

[asavonic]

In D98895#3118821, @eandrews wrote:

This patch causes a regression.

To reproduce - clang -cc1 -fsycl-is-device -triple spir64 test.cpp

test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' type support, but target 'spir64' does not support it
T bar() { return T(); };
  ^

I looked at it briefly, and I believe the issue is call to checkTypeSupport() in ActOnFinishFunctionBody(). I tried deleting the call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please take a look. I will be reverting the patch if this cannot be fixed soon.

The diagnostic seems to be correct - this instance of bar returns an unsupported type. Why do you think it should not be diagnosed?

[erichkeane]

In D98895#3119027, @asavonic wrote:

In D98895#3118821, @eandrews wrote:

This patch causes a regression.

To reproduce - clang -cc1 -fsycl-is-device -triple spir64 test.cpp

test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' type support, but target 'spir64' does not support it
T bar() { return T(); };
  ^

I looked at it briefly, and I believe the issue is call to checkTypeSupport() in ActOnFinishFunctionBody(). I tried deleting the call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please take a look. I will be reverting the patch if this cannot be fixed soon.

The diagnostic seems to be correct - this instance of bar returns an unsupported type. Why do you think it should not be diagnosed?

I believe the problem is that there are now _3_ different diagnostics for the same thing, the one on 'bar', plus 2 more here:

auto malAutoTemp5 = bar<__float128>();

I think i would expect 1 error on 'bar', 1 error on the deduced 'auto', but the 3rd is superfluous.

[asavonic]

In D98895#3119064, @erichkeane wrote:

In D98895#3119027, @asavonic wrote:

In D98895#3118821, @eandrews wrote:

This patch causes a regression.

To reproduce - clang -cc1 -fsycl-is-device -triple spir64 test.cpp

test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' type support, but target 'spir64' does not support it
T bar() { return T(); };
  ^

I looked at it briefly, and I believe the issue is call to checkTypeSupport() in ActOnFinishFunctionBody(). I tried deleting the call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please take a look. I will be reverting the patch if this cannot be fixed soon.

The diagnostic seems to be correct - this instance of bar returns an unsupported type. Why do you think it should not be diagnosed?

I believe the problem is that there are now _3_ different diagnostics for the same thing, the one on 'bar', plus 2 more here:

auto malAutoTemp5 = bar<__float128>();

I think i would expect 1 error on 'bar', 1 error on the deduced 'auto', but the 3rd is superfluous.

I will check if there is a way to filter it out. However, I don't think that it is a good reason to revert the patch.

[erichkeane]

In D98895#3119104, @asavonic wrote:

In D98895#3119064, @erichkeane wrote:

In D98895#3119027, @asavonic wrote:

In D98895#3118821, @eandrews wrote:

This patch causes a regression.

To reproduce - clang -cc1 -fsycl-is-device -triple spir64 test.cpp

test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' type support, but target 'spir64' does not support it
T bar() { return T(); };
  ^

I looked at it briefly, and I believe the issue is call to checkTypeSupport() in ActOnFinishFunctionBody(). I tried deleting the call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please take a look. I will be reverting the patch if this cannot be fixed soon.

The diagnostic seems to be correct - this instance of bar returns an unsupported type. Why do you think it should not be diagnosed?

I believe the problem is that there are now _3_ different diagnostics for the same thing, the one on 'bar', plus 2 more here:

auto malAutoTemp5 = bar<__float128>();

I think i would expect 1 error on 'bar', 1 error on the deduced 'auto', but the 3rd is superfluous.

I will check if there is a way to filter it out. However, I don't think that it is a good reason to revert the patch.

This a pretty significant regression in our downstream, which is typically more than enough to get a revert.

[eandrews]

In D98895#3119027, @asavonic wrote:

In D98895#3118821, @eandrews wrote:

This patch causes a regression.

To reproduce - clang -cc1 -fsycl-is-device -triple spir64 test.cpp

test.cpp:x:3: error: 'bar<__float128>' requires 128 bit size '__float128' type support, but target 'spir64' does not support it
T bar() { return T(); };
  ^

I looked at it briefly, and I believe the issue is call to checkTypeSupport() in ActOnFinishFunctionBody(). I tried deleting the call but it breaks tests (E.g. L26 in x86_64-no-x87.cpp). @asavonic Please take a look. I will be reverting the patch if this cannot be fixed soon.

The diagnostic seems to be correct - this instance of bar returns an unsupported type. Why do you think it should not be diagnosed?

@asavonic I spoke offline with @erichkeane. I was mistaken. There are only 2 error diagnostics generated (upstream) after this patch. The additional diagnostic generated at bar after your patch is correct. We just need to remove the third diagnostic downstream. So nothing needs to be done here. I apologize for the confusion and trouble.

[asavonic]

@asavonic I spoke offline with @erichkeane. I was mistaken. There are only 2 error diagnostics generated (upstream) after this patch. The additional diagnostic generated at bar after your patch is correct. We just need to remove the third diagnostic downstream. So nothing needs to be done here. I apologize for the confusion and trouble.

No worries. Thanks a lot for checking this.

[pengfei]

Disabled double or float return for x86 targets

Sorry, I think we still need to match GCC's behavior. I.e., we shouldn't diagnosticate any FP type (float, double, long double) on 32-bits. https://godbolt.org/z/KrbhfWc9o
We have users who require of that. Noticed this problem during D112143.
Could you have a look again?

clang/test/Sema/x86-no-x87.cpp

1 ↗

(On Diff #384364)

This seems not used?

22–24 ↗

(On Diff #384364)

I'd think we can't emit error diagnostics on 32-bits now. We have users who rely on such behavior.

[pengfei]

@asavonic , I put a patch D114162 to enable it on 32-bits. Could you help to review it?

[nickdesaulniers]

Linus Torvalds' thoughts on the patches as a result of this change.

Those uses of 1E6L were perhaps strange, but they were only used in
constant compile-time expressions that were cast to 'unsigned long' in
the end, so how the heck did llvm end up with any floating point in
there?

In this case there was really no excuse not to just use a better
constant, but there are other situations where it might well be quite
reasonable to use floating point calculations to create an integer
constant (eg maybe some spec describes an algorithm in FP, but the
implementation uses fixed-point arithmetic and has initializers that
do the conversion).

Imagine for a moment that you want to do fixed-point math (perhaps
because you have a microcontroller without an FP unit - it's not
limited to just "the kernel doesn't do FP"). Further imagine just for
a moment that you still want some fundamental constants like PI in
that fixed-point format.

The sane way to generate said constants is to do something like

#define FIXPT_1 (1u << FIXPT_SHIFT)
#define FIXPT_FP(x) ((fixpt_t) (((x)*FIXPT_1)+0.5))
#define FIXPT_PI FIXPT_FP(3.14159265)

rather than have to do something incredibly stupid and illogical and
unreadable like

#define FIXPT_PI 205887

So honestly, this seems to be just llvm being completely stupid. The
fact that you don't want to generate floating point code has *NOTHING*
to do with floating point literals for constant expressions.

In fact, even if you don't want to generate floating point code -
again, maybe you don't have a FP unit - doesn't mean that you might
not want to generate normal floating point constants. You may end up
having explicit software floating point, and doing things like passing
the floating point values around manually, ie

 union fp {
     uint64_t val;
     double fp_val;
};

and having code like

static const union fp sqrt2 = { .fp_val = 1.4142.... };

and then doing all the math in 'uint64_t' just because you wrote a
couple of math routines yourself:

fp_mul(&res,  sqrt2.val, x);

again, there's no floating point *code* generated, but that doesn't
mean that the compiler shouldn't allow users to use floating point
*values*.

The two
examples above are very much not about the Linux kernel (although I
think we actually have a couple of places that do things exactly like
that) they are about generic coding issues.

[erichkeane]

In D98895#3232453, @nickdesaulniers wrote:

Linus Torvalds' thoughts on the patches as a result of this change.

Those uses of 1E6L were perhaps strange, but they were only used in
constant compile-time expressions that were cast to 'unsigned long' in
the end, so how the heck did llvm end up with any floating point in
there?

In this case there was really no excuse not to just use a better
constant, but there are other situations where it might well be quite
reasonable to use floating point calculations to create an integer
constant (eg maybe some spec describes an algorithm in FP, but the
implementation uses fixed-point arithmetic and has initializers that
do the conversion).

Imagine for a moment that you want to do fixed-point math (perhaps
because you have a microcontroller without an FP unit - it's not
limited to just "the kernel doesn't do FP"). Further imagine just for
a moment that you still want some fundamental constants like PI in
that fixed-point format.

The sane way to generate said constants is to do something like

#define FIXPT_1 (1u << FIXPT_SHIFT)
#define FIXPT_FP(x) ((fixpt_t) (((x)*FIXPT_1)+0.5))
#define FIXPT_PI FIXPT_FP(3.14159265)

rather than have to do something incredibly stupid and illogical and
unreadable like

#define FIXPT_PI 205887

So honestly, this seems to be just llvm being completely stupid. The
fact that you don't want to generate floating point code has *NOTHING*
to do with floating point literals for constant expressions.

In fact, even if you don't want to generate floating point code -
again, maybe you don't have a FP unit - doesn't mean that you might
not want to generate normal floating point constants. You may end up
having explicit software floating point, and doing things like passing
the floating point values around manually, ie

 union fp {
     uint64_t val;
     double fp_val;
};

and having code like

static const union fp sqrt2 = { .fp_val = 1.4142.... };

and then doing all the math in 'uint64_t' just because you wrote a
couple of math routines yourself:

fp_mul(&res,  sqrt2.val, x);

again, there's no floating point *code* generated, but that doesn't
mean that the compiler shouldn't allow users to use floating point
*values*.

The two
examples above are very much not about the Linux kernel (although I
think we actually have a couple of places that do things exactly like
that) they are about generic coding issues.

I saw that and responded to it on the ClangBuiltLinux thread...

Generally, our policy is that we should do all our diagnostics in the CFE/Sema. I believe GCC implements this limitation in the code-generator, so the result is that depending on optimization settings, you don't get these errors. I'm going to disagree with Linus, from a language design perspective, if we want to decide a type is 'illegal', we need to do so consistently, not JUST when it shows up. The Clang project has had this opinion as long as I've been around, and we've had to have GCC incompatibilities in the past as a result. I don't see this as any different from what we have done before.

clang/include/clang/Basic/TargetInfo.h

protected:
   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;
   bool HasBFloat16;
+  bool HasLongDouble;
   bool HasStrictFP;
 
   unsigned char MaxAtomicPromoteWidth, MaxAtomicInlineWidth;
   unsigned short SimdDefaultAlign;
   std::unique_ptr<llvm::DataLayout> DataLayout;
   const char *MCountName;
   unsigned char RegParmMax, SSERegParmMax;
   TargetCXXABI TheCXXABI;
public:
   virtual bool hasFloat128Type() const { return HasFloat128; }
 
   /// Determine whether the _Float16 type is supported on this target.
   virtual bool hasFloat16Type() const { return HasFloat16; }
 
   /// Determine whether the _BFloat16 type is supported on this target.
   virtual bool hasBFloat16Type() const { return HasBFloat16; }
 
+  /// Determine whether the long double type is supported on this target.
+  virtual bool hasLongDoubleType() const { return HasLongDouble; }
+
   /// Determine whether constrained floating point is supported on this target.
   virtual bool hasStrictFP() const { return HasStrictFP; }
 
   /// Return the alignment that is the largest alignment ever used for any
   /// scalar/SIMD data type on the target machine you are compiling for
   /// (including types with an extended alignment requirement).
   unsigned getSuitableAlign() const { return SuitableAlign; }
 

clang/lib/Basic/TargetInfo.cpp

TargetInfo::TargetInfo(const llvm::Triple &T) : TargetOpts(), Triple(T) {
   BigEndian = !T.isLittleEndian();
   TLSSupported = true;
   VLASupported = true;
   NoAsmVariants = false;
   HasLegalHalfType = false;
   HasFloat128 = false;
   HasFloat16 = false;
   HasBFloat16 = false;
+  HasLongDouble = true;
   HasStrictFP = false;
   PointerWidth = PointerAlign = 32;
   BoolWidth = BoolAlign = 8;
   IntWidth = IntAlign = 32;
   LongWidth = LongAlign = 32;
   LongLongWidth = LongLongAlign = 64;
 
   // Fixed point default bit widths

clang/lib/Basic/Targets/X86.h

class LLVM_LIBRARY_VISIBILITY X86TargetInfo : public TargetInfo {
   bool HasHRESET = false;
   bool HasAVXVNNI = false;
   bool HasAMXTILE = false;
   bool HasAMXINT8 = false;
   bool HasAMXBF16 = false;
   bool HasSERIALIZE = false;
   bool HasTSXLDTRK = false;
   bool HasUINTR = false;
+  bool HasX87 = false;
 
 protected:
   llvm::X86::CPUKind CPU = llvm::X86::CK_None;
 
   enum FPMathKind { FP_Default, FP_SSE, FP_387 } FPMath = FP_Default;
 
 public:
   X86TargetInfo(const llvm::Triple &Triple, const TargetOptions &)

clang/lib/Basic/Targets/X86.cpp

for (const auto &Feature : Features) {
     } else if (Feature == "+avxvnni") {
       HasAVXVNNI = true;
     } else if (Feature == "+serialize") {
       HasSERIALIZE = true;
     } else if (Feature == "+tsxldtrk") {
       HasTSXLDTRK = true;
     } else if (Feature == "+uintr") {
       HasUINTR = true;
+    } else if (Feature == "+x87") {
+      HasX87 = true;
     }
 
     X86SSEEnum Level = llvm::StringSwitch<X86SSEEnum>(Feature)
                            .Case("+avx512f", AVX512F)
                            .Case("+avx2", AVX2)
                            .Case("+avx", AVX)
                            .Case("+sse4.2", SSE42)
                            .Case("+sse4.1", SSE41)
if ((FPMath == FP_SSE && SSELevel < SSE1) ||
       (FPMath == FP_387 && SSELevel >= SSE1)) {
     Diags.Report(diag::err_target_unsupported_fpmath)
         << (FPMath == FP_SSE ? "sse" : "387");
     return false;
   }
 
   SimdDefaultAlign =
       hasFeature("avx512f") ? 512 : hasFeature("avx") ? 256 : 128;
+
+  if (!HasX87 && LongDoubleFormat == &llvm::APFloat::x87DoubleExtended()) {
+    HasLongDouble = false;
+  }
+
   return true;
 }
 
 /// X86TargetInfo::getTargetDefines - Return the set of the X86-specific macro
 /// definitions for this particular subtarget.
 void X86TargetInfo::getTargetDefines(const LangOptions &Opts,
                                      MacroBuilder &Builder) const {
   // Inline assembly supports X86 flag outputs.
return llvm::StringSwitch<bool>(Feature)
       .Case("uintr", HasUINTR)
       .Case("vaes", HasVAES)
       .Case("vpclmulqdq", HasVPCLMULQDQ)
       .Case("wbnoinvd", HasWBNOINVD)
       .Case("waitpkg", HasWAITPKG)
       .Case("x86", true)
       .Case("x86_32", getTriple().getArch() == llvm::Triple::x86)
       .Case("x86_64", getTriple().getArch() == llvm::Triple::x86_64)
+      .Case("x87", HasX87)
       .Case("xop", XOPLevel >= XOP)
       .Case("xsave", HasXSAVE)
       .Case("xsavec", HasXSAVEC)
       .Case("xsaves", HasXSAVES)
       .Case("xsaveopt", HasXSAVEOPT)
       .Default(false);
 }
 

clang/lib/Sema/SemaChecking.cpp

bool Sema::CheckFunctionCall(FunctionDecl *FDecl, CallExpr *TheCall,
   if (!FnInfo)
     return false;
 
   CheckTCBEnforcement(TheCall, FDecl);
 
   CheckAbsoluteValueFunction(TheCall, FDecl);
   CheckMaxUnsignedZero(TheCall, FDecl);
 
+  if (!Context.getTargetInfo().hasLongDoubleType()) {
+    if (Proto->getReturnType().getCanonicalType() == Context.LongDoubleTy) {
+      Diag(TheCall->getExprLoc(), diag::err_type_unsupported) << "long double";
+    }
+    for (ParmVarDecl *Param : FDecl->parameters()) {
+      if (Param->getType().getCanonicalType() == Context.LongDoubleTy) {
+        Diag(Param->getLocation(), diag::err_type_unsupported) << "long double";
+      }
+    }
+  }
+
   if (getLangOpts().ObjC)
     DiagnoseCStringFormatDirectiveInCFAPI(*this, FDecl, Args, NumArgs);
 
   unsigned CMId = FDecl->getMemoryFunctionKind();
 
   // Handle memory setting and copying functions.
   switch (CMId) {
   case 0:
if (LangOpts.CPlusPlus && !Param->isInvalidDecl()) {
       if (DC && DC->isFunctionOrMethod()) {
         if (auto *RD = dyn_cast<CXXRecordDecl>(DC->getParent()))
           CheckShadowInheritedFields(Param->getLocation(), Param->getDeclName(),
                                      RD, /*DeclIsField*/ false);
       }
     }
   }
 
   return HasInvalidParm;
 }
 
 Optional<std::pair<CharUnits, CharUnits>>
 static getBaseAlignmentAndOffsetFromPtr(const Expr *E, ASTContext &Ctx);
 
 /// Compute the alignment and offset of the base class object given the
 /// derived-to-base cast expression and the alignment and offset of the derived
 /// class object.

clang/lib/Sema/SemaDecl.cpp

NamedDecl *Sema::ActOnVariableDeclarator(
 
   if (getLangOpts().OpenCL) {
 
     deduceOpenCLAddressSpace(NewVD);
 
     diagnoseOpenCLTypes(S, *this, D, DC, NewVD->getType());
   }
 
+  if (!Context.getTargetInfo().hasLongDoubleType() &&
+      NewVD->getType().getCanonicalType() == Context.LongDoubleTy) {
+    Diag(NewVD->getLocation(), diag::err_type_unsupported) << "long double";
+  }
+
   // Handle attributes prior to checking for duplicates in MergeVarDecl
   ProcessDeclAttributes(S, NewVD, D);
 
   if (getLangOpts().CUDA || getLangOpts().OpenMPIsDevice ||
       getLangOpts().SYCLIsDevice) {
     if (EmitTLSUnsupportedError &&
         ((getLangOpts().CUDA && DeclAttrsMatchCUDAMode(getLangOpts(), NewVD)) ||
          (getLangOpts().OpenMPIsDevice &&
if (getLangOpts().OpenCL) {
     LangAS AddressSpace = NewFD->getReturnType().getAddressSpace();
     if (AddressSpace != LangAS::Default) {
       Diag(NewFD->getLocation(),
            diag::err_opencl_return_value_with_address_space);
       NewFD->setInvalidDecl();
     }
   }
 
   if (LangOpts.SYCLIsDevice || (LangOpts.OpenMP && LangOpts.OpenMPIsDevice))
     checkDeviceDecl(NewFD, D.getBeginLoc());
 
   if (!getLangOpts().CPlusPlus) {
     // Perform semantic checking on the function declaration.
     if (!NewFD->isInvalidDecl() && NewFD->isMain())
       CheckMain(NewFD, D.getDeclSpec());
 
     if (!NewFD->isInvalidDecl() && NewFD->isMSVCRTEntryPoint())
       CheckMSVCRTEntryPoint(NewFD);
Decl *Sema::ActOnStartOfFunctionDef(Scope *FnBodyScope, Decl *D,
 
   if (FnBodyScope)
     PushDeclContext(FnBodyScope, FD);
 
   // Check the validity of our function parameters
   CheckParmsForFunctionDef(FD->parameters(),
                            /*CheckParameterNames=*/true);
 
+  if (!Context.getTargetInfo().hasLongDoubleType()) {
+    if (ResultType.getCanonicalType() == Context.LongDoubleTy) {
+      Diag(FD->getLocation(), diag::err_type_unsupported) << "long double";
+    }
+    for (ParmVarDecl *Param : FD->parameters()) {
+      if (Param->getType().getCanonicalType() == Context.LongDoubleTy) {
+        Diag(Param->getLocation(), diag::err_type_unsupported) << "long double";
+      }
+    }
+  }
+
   // Add non-parameter declarations already in the function to the current
   // scope.
   if (FnBodyScope) {
     for (Decl *NPD : FD->decls()) {
       auto *NonParmDecl = dyn_cast<NamedDecl>(NPD);
       if (!NonParmDecl)
         continue;
       assert(!isa<ParmVarDecl>(NonParmDecl) &&

clang/lib/Sema/SemaExpr.cpp

if (LHSTy->isImageType() || RHSTy->isImageType() ||
         LHSTy->isSamplerT() || RHSTy->isSamplerT() ||
         LHSTy->isPipeType() || RHSTy->isPipeType() ||
         LHSTy->isBlockPointerType() || RHSTy->isBlockPointerType()) {
       ResultTy = InvalidOperands(OpLoc, LHS, RHS);
       return ExprError();
     }
   }
 
+  if (!Context.getTargetInfo().hasLongDoubleType()) {
+    QualType LHSTy = LHSExpr->getType();
+    QualType RHSTy = RHSExpr->getType();
+
+    if ((LHSTy.getCanonicalType() == Context.LongDoubleTy) ||
+        (RHSTy.getCanonicalType() == Context.LongDoubleTy)) {
+      Diag(OpLoc, diag::err_type_unsupported) << "long double";
+      return ExprError();
+    }
+  }
+
   switch (Opc) {
   case BO_Assign:
     ResultTy = CheckAssignmentOperands(LHS.get(), RHS, OpLoc, QualType());
     if (getLangOpts().CPlusPlus &&
         LHS.get()->getObjectKind() != OK_ObjCProperty) {
       VK = LHS.get()->getValueKind();
       OK = LHS.get()->getObjectKind();
     }
ExprResult Sema::CreateBuiltinUnaryOp(SourceLocation OpLoc,
 
   // Check for array bounds violations in the operand of the UnaryOperator,
   // except for the '*' and '&' operators that have to be handled specially
   // by CheckArrayAccess (as there are special cases like &array[arraysize]
   // that are explicitly defined as valid by the standard).
   if (Opc != UO_AddrOf && Opc != UO_Deref)
     CheckArrayAccess(Input.get());
 
+  if (!Context.getTargetInfo().hasLongDoubleType() &&
+      (resultType.getCanonicalType() == Context.LongDoubleTy ||
+       InputExpr->getType().getCanonicalType() == Context.LongDoubleTy)) {
+    Diag(OpLoc, diag::err_type_unsupported) << "long double";
+    return ExprError();
+  }
+
   auto *UO =
       UnaryOperator::Create(Context, Input.get(), Opc, resultType, VK, OK,
                             OpLoc, CanOverflow, CurFPFeatureOverrides());
 
   if (Opc == UO_Deref && UO->getType()->hasAttr(attr::NoDeref) &&
       !isa<ArrayType>(UO->getType().getDesugaredType(Context)) &&
       !isUnevaluatedContext())
     ExprEvalContexts.back().PossibleDerefs.insert(UO);

clang/test/Sema/x86-no-x87.c

+// RUN: %clang_cc1 -fsyntax-only -verify %s -triple x86_64-linux-gnu -target-feature -x87
+// RUN: %clang_cc1 -fsyntax-only -verify %s -triple x86_64-linux-gnu -DNOERROR
+
+#ifdef NOERROR
+// expected-no-diagnostics
+#endif
+
+typedef long double long_double;
+
+#ifndef NOERROR
+// expected-error@+3{{long double is not supported on this target}}
+// expected-error@+2{{long double is not supported on this target}}
+#endif
+double ld_args(long_double x, long_double y);
+
+long_double ld_ret(double x, double y);
+
+double args(double x, double y) {
+  return ld_args(x, y);
+}
+
+double ret(double x, double y) {
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  return ld_ret(x, y);
+}
+
+double binop(double x, double y) {
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  double z = (long_double)x * (long_double)y;
+  return z;
+}
+
+void assign1(long_double *ret, double x) {
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  *ret = x;
+}
+
+struct st_long_double {
+  long_double ld;
+};
+
+void assign2() {
+  struct st_long_double st;
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  st.ld = 0.42;
+}
+
+void assign3() {
+#ifndef NOERROR
+  // expected-error@+2{{long double is not supported on this target}}
+#endif
+  long_double ld = 0.42;
+}