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] Relax restrictions on KIND in SELECT CASE constructs


On Tue, Dec 28, 2004 at 11:09:02AM -0800, Steve Kargl wrote:
> On Mon, Dec 27, 2004 at 09:27:23AM -0800, Steve Kargl wrote:
> > On Mon, Dec 27, 2004 at 01:46:16PM +0000, Paul Brook wrote:
> > > > 2004-12-17  Steven G. Kargl  <kargls@comcast.net>
> > > >
> > > >      * resolve.c (validate_case_label_expr): Fix handling of mismatched
> > > > KINDs.
> > > 
> > > No.
> > 
> > Okay, I'll open a PR about this problem.  I have no idea 
> > how to fix this at the moment.
> > 
> 
> I just re-read Pauls original reply and I think his suggestion 
> is incorrect with respect to 7.2.3 of the standard.  I deleted
> his email so, I'm reproducing it here:
> 
> > program foo
> >   integer i
> >   select case (i)
> >   case (0_4)
> >   case (1_8)
> >   end select
> > end program
> > 
> > Gives:
> > 
> >       SELECT CASE __convert_i4_i8[[((i))]]
> >       CASE (0 0)
> >       CASE (1_8 1_8)
> >       END SELECT
> > 
> > Which is obviously wrong.
> > 
> > We should probably convert all cases to the type of the select
> > expression.  Out of range values should either error, or warn
> > and remove that case.
> 
> I think this is wrong because we need to convert "i == 1_8" to the 
> KIND of i + 1_8 per 7.2.3, which has the kind of 1_8.  The passage
> from the standard is
> 
>   In the numeric relational operation
>          x1 rel-op x2
>   if the types or kind type parameters of x1 and x2 differ, their values
>   are converted to the type and kind type parameter of the expression
>   x1 + x2 before evaluation.
> 
> Since the conversion must be performed before evaluation, we may now
> conclude that in principle there are no out-of-range values.  Note,
> this does not mean that certain cases are not unreachable.  For example,
> 
>    integer*1 i        ! kind = 1, -128 <= i < 127
>    select case (i)    ! need to convert i to kind = 4.
>    case (1)           ! kind = 4, reachable
>    case (200)         ! kind = 4, unreachable because of range of i
>    end select 
> 
> The question becomes more complicated with a slight variation of 
> Paul's example.
> 
>    integer*1 i        ! kind = 1, -128 <= i < 127
>    select case (i)    !
>    case (1_4)         ! kind = 4, reachable
>    case (2_8)         ! kind = 8, reachable
>    end select 
> 
> Do we convert i and 1_4 to kind = 8?  Do we convert i to kind = 4
> in the comparison with 1_4 and convert it to kind = 8 in the 
> comparison with 2_8?   It is probably safe to convert everything to 
> the largest kind, because the smaller kind are proper subsets
> of the larger kinds. 
> 

With the overwhelming support of the gfortran community,
I've implemented the first choice.  The attached patch
is the result of this effort and the 3 additional test
case do what I expect.  These test cases should be committed
along with the test cases posted here:
http://gcc.gnu.org/ml/fortran/2004-12/msg00260.html

This patch walks the list of case values/ranges and
adjusts the kind of case expression if needed.  It
then adjusts the kind of the case/values/ranges
during validation.  As per 7.2.3, no warning of the
kind conversion are necesssary, so I did not issue
any warnings.

Bootstrapped and regression tested on i386-*-freebsd6.0.

Additional test cases are provided.
Please commit.

2005-01-01  Steven G. Kargl  <kargls@comcast.net>

      PR 19168
      *resolve.c (check_case_overlap): Typo in comment
      (validate_case_label_expr):  Fix up kinds of case values
      (resolve_select): Properly handle kind mismatches.

-- 
Steve

Attachment: resolve.c.diff
Description: Text document

Attachment: select_7.f90
Description: Text document

Attachment: select_8.f90
Description: Text document

Attachment: select_9.f90
Description: Text document


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