This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]