Why is the -qkind= option not -fqkind=?

[Brooks Moses]

Steve Kargl wrote:
> On Tue, Nov 07, 2006 at 12:57:10AM -0800, Brooks Moses wrote:
>>PR 28122 lists several undocumented GFortran options; among them is 
>>-qkind=<value>.  This sticks out rather like a sore thumb, with nearly 
>>every other command-line option starting with -f or -warn.  Is there 
>>some reason why this one doesn't?  Should I change it to fit the 
>>standard pattern before documenting it?
> 
> I think it is a historical artifact from the initial integration
> of g95.  I concur with you that it should be renamed to -fqkind.
> I also think you can drop -qkind without concerns for backwards
> compatibility.

Looks like there's no backwards compatibility to lose -- currently, it 
doesn't work at all, apparently because of the lack of the leading "f" 
(which seems to be doing something with regards to whether the option 
gets passed along from gfortran to f951).  Note the discrepancy in the 
two error messages, below:

 > gfortran -qkind=4 qkind_1.f90
gfortran: unrecognized option '-qkind=4'
  In file qkind_1.f90:5

   if (kind(1.0q0) /= 4) call abort()
                1
  Internal Error at (1):
  gfc_validate_kind(): Got bad kind

 > gfortran -fqkind=4 qkind_1.f90
f951: error: unrecognized command line option "-fqkind=4"

Besides the flag problems, the default kind for the 'q' exponent is 
broken and produces an ICE -- because, in option.c, the default value is 
set to gfc_default_double_kind, but the default double kind hasn't been 
set yet (and can't be set, until after the options are parsed).  So 
setting a reasonable default will need to be handled in trans-types.c.

Furthermore, since this is a nonstandard extension, there ought to be an 
error showing up about it with -std=f95 (but only when -qkind= isn't 
given!), and there isn't.  This would need to be added to primary.c.

And, obviously, we'll need to add at least one testcase for it.

I suppose it's not that much more work to make it work right rather than 
deleting it.  On the other hand, there's something to be said for not 
supporting excessive extensions that (apparently) nobody ever uses, 
particularly when they start blooming into complicated maintenance 
headaches like this one seems to be.  Besides which, there's now a 
standard way to accomplish the same end goal by specifying an explicit 
kind on the number.

So, I'll be glad to fix it if anyone thinks it's worth having, but 
otherwise I'm going to propose just ripping it out.

- Brooks