[patch,fortran] Fix PR19310 unnecessary error for overflowing results

[Jerry DeLisle]

Paul Brook wrote:
>>Well, maybe we should clarify the policy here.  I think that the only
>>reason we need a negative form is in the case where a behavior is invoked
>>by another flag that enables or disables more than one feature and you only
>>want part of that invoked.
>>
>>So we only need to turn off a feature if we need to over-ride some other
>>invocation that invokes it.
>>
>>In the case of -fno-range-check (or whatever you call it) the feature is
>>mutually exclusive from other compiler directives and so the negative form
>>is not needed.
>>
>>This may be true for other cases where we have not RejectNegative and we
>>ought to likewise set those RejectNegative.
>>
>>Therefore, I think we ought to have the RejectNegative in this case and I
>>should go back and add in for the other flags that are of this nature.
>>
>>Paul, do you agree?
> 
> 
> In short, no I don't agree.
> 
> I think prior art in gcc is strongly towards having both forms of the option. 
> I thing we're agreed that this is a binary option. ie. both the positive and 
> negative variants are meaningful, even if one is only re-affirming the 
> default.
> 
> Whether it happens to be enabled by other options is IMHO irelevant. What's to 
> say we won't decide in 6 months time that we want to add a new option 
> (eg. -fallow-everything) that implies -fno-range-check by default?
> 
> Paul
> 
OK, how about if I call it -frange-check, have that be the default, and the 
reverse be -fno-range-check.

Does that satisfy the norm?  I am just trying to be clear.

Jerry