[Bug fortran/48426] [patch] Quad precision promotion

["inform at tiker dot net" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426

--- Comment #6 from Andreas Kloeckner <inform at tiker dot net> 2011-04-05 02:12:33 UTC ---
(In reply to comment #4)
> On Sun, Apr 03, 2011 at 07:49:53PM +0000, inform at tiker dot net wrote:
> This is the number one reason why these options (including the
> current 3 [1]) should not be available in any compiler. Few people
> use these types of options for debugging.  Most have a single
> precision algorithm, but want a double (or higher) precision
> routine.  Instead of actually trying to understand and implement
> a proper double (or higher) precision version, people simply use
> these types of options without checking the robustness of the 
> algorithm.

First, some use of type promotion is--at least to some extent--legitimate. If
you would like to use a certain piece of code in single and double precision
and maintain compatibility with pure F77, then having the compiler able to
rewrite your code is a useful thing to have available. Second, as I explained,
there are uses of this in debugging. Obviously, maintaining multiple versions
of the source code is not really an option in this case especially. To
reiterate, the practical use of these flags should not be underestimated.

Further, trying to convince users by not implementing this feature will simply
drive them away from free tools. The need exists.

> In glancing at the patch, there are at least two problems.  First,
> this chunk 
> 
> +  else if (saw_i8 && gfc_option.flag_integer4_kind == 8 )
> +    {
> +      gfc_default_integer_kind = 8;
> +
> +      /* Even if the user specified that the default integer kind be 8,
> +         the numeric storage size isn't 64.  In this case, a warning will
> +     be issued when NUMERIC_STORAGE_SIZE is used.  */
> +      gfc_numeric_storage_size = 4 * 8;
> +    }
> 
> is simply a bad idea.

This just imitates the behavior of -fdefault-integer-8, whose treatment is
right directly above this snippet. So if our code is broken, so is the code for
the existing flag.

> Second, this chunk 
> 
> +  if (ts->type == BT_REAL || ts->type == BT_COMPLEX)
> +    {
> +      if( ts->kind == 4 && gfc_option.flag_real4_kind ==  8) ts->kind =  8;
> +      if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10;
> +      if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16;
> +      if( ts->kind == 8 && gfc_option.flag_real8_kind ==  4) ts->kind =  4;
> +      if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10;
> +      if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16;
> 
> appears to assume that ts->kind=10 and ts->kind=16 are available. 
> This may or may not be true depending on the target and the options
> used during execution of configure.  One needs to check if 10 and 16
> are available.

Fixed in an updated version of the patch.