[llvm] [Flang-rt][build] fixes building warnings under gcc: (PR #173955)

[liao jun via llvm-commits]

================
@@ -452,7 +452,13 @@ float RTNAME(Rand)(int *i, const char *sourceFile, int line) {
   if (radix == 2) {
     mask = ~(unsigned)0u << (32 - digits + 1);
   } else if (radix == 16) {
-    mask = ~(unsigned)0u << ((8 - digits) * 4 + 1);
+    int shift_val = ((8 - digits) * 4 + 1);
+    if (shift_val < 0) {
+      Terminator terminator{sourceFile, line};
+      terminator.Crash("Radix 16: negative shift for mask. digits value maybe invalid.");
+    } else {
+      mask = ~(unsigned)0u << shift_val;
+    }
----------------
zjlcd wrote:

It's very strange, I still have not found any description of hexadecimal floating-point formats in the IEEE-754-2019 document(https://www-users.cse.umn.edu/~vinals/tspot_files/phys4041/2020/IEEE%20Standard%20754-2019.pdf).

I think it might be like this: the current implementation of the rand function in the `extensions.cpp` file is actually not much different from the implementation of the rand function in the GNU extension(gfortran). It can be found that support for the rand function in the GNU extension is implemented in `libgfortran/intrinsic/rand.c`, where there is also the case of `radix==16`. However, considering that the value of `GFC_REAL_4_RADIX` is defined in the `kinds.h` file (generated at compile time by libgfortran/mk-kinds-h.sh), and the value is 2, I could not find a definition of 16 in the GCC source code tree, which makes the case of `radix==16` very confusing to me.

In addition, in my humble opinion, according to the description in IEEE-754-2019, based on examples of binary and decimal numbers, it seems possible to find formulas for calculating the digits values in other bases:
                                        `digits(base) = digits(2)/log2(base)`

e.g :   binray64's digits is 53, so the result of decimal64's digits:  `digits(10) = 53/log2(10)`, the result is 15.95, this result is quite close to the actual result.

So, if the hexadecimal floating-point numbers described in IEEE-754-2019 really exist, then the corresponding values of radix and digits should be 16 and 6 respectively(hexadecimal32), and `8-digits` result would not be negative. In that case, I do not understand why the GCC compiler still gives warnings, or it's some other reason.

@eugeneepshteyn,  @JDPailleux , Please forgive me if I have offended you.

https://github.com/llvm/llvm-project/pull/173955