different behaviours for double precision on different compiler

Question 1

The IEEE 754 64-bit binary result is GT.

The two exactly representable values bracketing 9.8 are:

9.7999999999999989341858963598497211933135986328125
9.800000000000000710542735760100185871124267578125

The second one is closer to 9.8, so it should be chosen in the normal rounding mode. It is slightly larger than 9.8, resulting in a product that is slightly larger than would have been produced in real number arithmetic, 3969.00000000000045474735088646411895751953125. The conversion of v to double is exact, as is the v*v multiplication. The result is division of a number slightly greater than 3969 by 3969. The rounded result is 1.0000000000000002220446049250313080847263336181640625

Question 2

The conversion from decimal fraction to a binary fraction is precise only if the decimal fraction can be summed up by binary fractions like 0.5, 0.25, ..., etc.

The number 9.8 in your example contains the fraction 0.8, which can not be represented as an exact fraction using binary number system. Thus different compilers will give you different results depending on the precision to represent fractional numbers.

Run your program using the number 9.75, then all the compilers will give you the same result, because

0.75 = 0.25 + 0.125 = 2^-2 + 2^-3

So the number 9.75 can be represented exactly by using binary fractions.

Question 3

The difference likely occurs when d * g is evaluated, because the mathematical result of that product must be rounded upward to produce a value representable in double, but the long double result is more accurate.

Most compilers convert 405 and 63 to double exactly and convert 9.8 to 9.800000000000000710542735760100185871124267578125, although the C++ standard gives them some leeway. The evaluation of v * v is also generally exact, since the mathematical result is exactly representable.

Commonly, on Intel processors, compilers evaluate d * g in one of two ways: Using double arithmetic or using long double with Intel’s 80-bit floating-point format. When evaluated with double, 405•9.800000000000000710542735760100185871124267578125 produces 3969.00000000000045474735088646411895751953125, and dividing this by 3969 yields a number slightly greater than one.

When evaluated with long double, the product is 3969.000000000000287769807982840575277805328369140625. The product, although greater than 3969, is slightly less, and dividing it by 3969 using long double arithmetic produces 1.000000000000000072533125339280246635098592378199100494384765625. When this value is assigned to r, the compiler is required to convert it to double. (Extra precision may be used only in intermediate expressions, not in assignments or casts.) This value is sufficient close to one that rounding it to double produces one.

You can mitigate some (but not all) of the variation between compilers by using casts or assignments with each individual operation:

double t0 = d * g;
double t1 = v * v;
double r = t0/t1;

Question 4

To answer your question: since the expression ought to evaluate to "equal", the test r>1.0 should be false, and the result printed should be "LE".

In reality you are running into the problem that a number like 9.8 cannot be represented exactly as a floating point number (there a hundreds of good links on the web to explain why this is so). If you need exact math, you have to use integers. Or bigDecimal. Or some such thing.

Question 5

I tested the code, this should return GT.

int main() {
    double d = 405.0f, g = 9.8f, v = 63.0f;
    double r = d * g / (v * v);
    printf("%s\n",(r>1.0f)?"GT":"LE");
}

GCC compiler sees 405 as int, so "double d = 405" is actually "double d = (double) 405".