http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426
--- Comment #4 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-04-03 20:33:12 UTC --- On Sun, Apr 03, 2011 at 07:49:53PM +0000, inform at tiker dot net wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426 > > --- Comment #3 from Andreas Kloeckner <inform at tiker dot net> 2011-04-03 > 19:49:51 UTC --- > (In reply to comment #2) > > There is already -fdefault-real-8, -fdefault-integer-8, and > > -fdefault-double-8. This is already 3 too many hacks. Adding > > an additional 7 options is 7 too many. > > From a purist perspective, I absolutely gree with you. Practically > however, in dealing with legacy codes (*), the value of being able > to do this should not be underestimated. If this was a useless thing > to do, why would Lahey/Fujitsu have included these flags? > > (*) Let's face it, a big part of Fortran's relevance stems from legacy codes. 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. 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. If one changes gfc_default_integer_kind to 8, then the numeric storage size should be updated to 8 * 8. I suspect (but haven't checked) that the above breaks not only EQUIVALENCE and COMMON but several assumptions within libgfortran. 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. > (As an anecdote, I once worked at an unnamed US national lab, and one of my > group's main reasons *against* adoption of g77 was the absence of > -fdefault-real-8.) Hopefully, the unnamed national lab wasn't using options like these with critical software without actually checking the robustness of the code. [1] I'm the person who did the initial clean-up of the poorly implemented -r8, -i8, and -d8 options (See ChangLog-2005). Others after me fixed my fixes. In rectrospect, I wish I had simply removed these options because the options probably do not do what a user thinks.
