[Fortran] RFC / RFA patch for using build_predict_expr instead of builtin_expect / PR 58721

[Dominique Dhumieres]

Hi Tobias,

> ... However, it will lead to a bunch of run-time segfaults in the test suite ...

You are quite pessimistic, aren't you? The only test failing is 
gfortran.dg/elemental_optional_args_5.f03 with -O0 (-Os and -m32/64 and -O1 
and -m32 for x86_64-apple-darwin10). This is fixed by removing the statement:

+	      gfc_add_expr_to_block (&err_block,
+				     build_predict_expr (PRED_ZERO, NOT_TAKEN));

in gcc/fortran/trans-expr.c. This change

                sub_t (&v[S.11 + -1], (logical(kind=4)) __builtin_expect ((integer(kind=8)) (D.2021 == 0B), 0) ? 0B : &(*D.2021)[(S.11 + D.2025) + D.2022], &0);

back to the original

                sub_t (&v[S.11 + -1], D.2027 != 0B ? &(*D.2027)[(S.11 + D.2031) + D.2028] : (void) 0, &0);

>From the comment above the statement, this convoluted construct is intended 
to make the scalarizer happy. Since I don't see how to write a code with 
optional arguments not known at compilation time, I think there is no need 
of __builtin_expect for these constructs, the switch being replaced with
the proper values after the constant propagation.

I have also notice another place where the code seems unnecessary convoluted:

         overflow.17 = 0;
-        if ((logical(kind=4)) __builtin_expect ((integer(kind=8)) (overflow.17 != 0), 0))
+        if (overflow.17 != 0)
           {
             _gfortran_runtime_error (&"Integer overflow when calculating the amount of memory to allocate"[1]{lb: 1 sz: 1});
           }
	 else
	 ...

I cannot see under wich circumstances the IF branche can be taken and
why the compiler does not generate the else branch only.

With the above change the patch regtests cleanly and fixes pr58721 and
pr59487.

Thanks for the patch,

Dominique