This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch,fortran] Fix PR19310 unnecessary error for overflowing results
- From: Paul Brook <paul at codesourcery dot com>
- To: Jerry DeLisle <jvdelisle at verizon dot net>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, gcc-patches at gcc dot gnu dot org, Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Date: Sat, 10 Jun 2006 02:04:36 +0100
- Subject: Re: [patch,fortran] Fix PR19310 unnecessary error for overflowing results
- References: <44890B76.6090808@verizon.net> <200606092145.14507.paul@codesourcery.com> <448A1372.1030108@verizon.net>
> 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