If not, why not?

The other answer beautifully covered the "yes" part of the question, let me elaborate on the opposite, on why using Intel x87 80-bit floating point is a bad idea. It's about printers and configurations. But mostly printers.

Let's suppose you work in numeric intensive software. Be it science, engineering or finance. Your code is very well thought out, uses only carefully selected algorithms, and also is verified against the usual hard topics is floating point hell business.

But there is this big client, that uses your software heavily, in thousands of identical machines, and where in some of said identical machines, sometimes, the answers go wrong, and diverge from all other identical machines.

And it's because someone printed something in the morning. Obviously.

In another big client, things are even worse, because again, on another hundred identical machines, running identical software, your software only sometimes simply dies, with hardware exceptions related to floating point numbers, only in your code.

And it's because someone printed something in the evening. Also obviously.

And I said this is obvious because any debugging session involving floating point arithmetic starts by installing the client's print drivers and hitting Ctrl+P, right?

The common topic above is that, by the characteristic of x87 floating point hardware being software configurable, precision and exceptions, this means there is almost no sensible way to guarantee reproducible results on the same machine, with the same inputs, with the same configurations, because these configurations can be changed by other code.

If not, why not?

The other answer beautifully covered the "yes" part of the question, let me elaborate on the opposite, on why using Intel x87 80-bit floating point hardware is a bad idea. It's about printers and configurations. But mostly printers.

Let's suppose you work in numeric intensive software. Be it science, engineering or finance. Your code is very well thought out, uses only carefully selected algorithms, and also is verified against the usual hard topics is floating point hell business.

But there is this big client, that uses your software heavily, in thousands of identical machines, and where in some of said identical machines, sometimes, the answers go wrong, and diverge from all other identical machines.

And it's because someone printed something in the morning. Obviously.

In another big client, things are even worse, because again, on another hundred identical machines, running identical software, your software only sometimes simply dies, with hardware exceptions related to floating point numbers, only in your code.

And it's because someone printed something in the evening. Also obviously.

And I said this is obvious because any debugging session involving floating point arithmetic starts by installing the client's print drivers and hitting Ctrl+P, right?

The common topic above is that, by the characteristic of x87 floating point hardware having global software configurations, particularly precision, instead of more "sensible" approach of per thread configuration, means there is almost no sensible way to guarantee reproducible results on the same machine, with the same inputs, with the same configurations, because these configurations can be changed by other code.

Note that specialists consider software configurable floating point hardware as something beneficial (particularly rounding). Not only beneficial, but it is probably the only way to externally test floating point code/libraries, in already compiled form.

But only if these configurations are never changed, nor these changes can be bypassed at instruction level, or this type of testing becomes invalid. This matters in Intel x87 because Wintel. From Wintel we have Microsoft, and from Microsoft we have C/C++ compilers that leave fp hardware in a configuration that depends on loading order of DLLs. Really.

Or even worse, Microsoft C compilers that will impedes any C programmer to observe certain floating point status/exceptions.

So to answer the title of questions, there are even C compilers that prohibits you from fully using Intel x87 80-bit floating point.