Re: g95 wish list

From: David Ham (d.a.ham_at_citg.tudelft.nl)
Date: 11/30/04 

Date: Tue, 30 Nov 2004 11:21:05 +0100

On Mon, 29 Nov 2004 10:23:04 +0000
Catherine Rees Lay <spamtrap@polyhedron.org.uk> wrote:

> In article <87ekig1p2r.fsf@vega.site>, Richard Maine
> <nospam@see.signature> writes
> >Andy Vaught <andy@firstinter.net> writes:
> >
> >> On Fri, 5 Nov 2004, Charles Russell wrote:
> >>
> >>> Low priority:
> >>>
> >>> 1. DIMENSION X(1) is semantically equivalent in old code to
> >DIMENSION X(*).>> g77 fails to recognize this when bounds check is
> >enabled. It would be nice>> to fix that.
> >>
> >> It isn't really equivalent. What if you are passing an array with
> >one> element, or a multiple-dimension array that has an extent of one
> >in a> dimension?
> >
> >Yes, making these completely equivalent makes it impossible to do
> >bounds checking on arrays that actually *DO* have bounds of 1. Such
> >arrays exist. Disabling bounds checking on them would be a
> >shortcomming.
> >
> >I've seen compilers where there were command-line switches to enable
> >this hack. If one feels the need to support bounds checking for old
> >codes with this hack, I'd say that made a lot more sense than
> >crippling bounds checking so that it can never work on some arrays.
> >
> I don't follow this. If you treat DIMENSION X(1) as DIMENSION X(*) and
>
> an array with one element in it is passed, it's perfectly possible to
> have a bounds check which fails if the subroutine references X(2).
>
> There are, and have been for years, compilers which do bounds-checking
>
> on arrays with bounds of * (this is one of the tests in the Polyhedron
>
> benchmarks).
>
> The only problem I can see is that if you always treat 1 as *, you
> lose the possibility of a check as to whether you passed an array of
> size 2 to a subroutine where it is declared explicitly as size 1 and
> was actually supposed to be size 1. Both you and the compiler would
> have to be psychic to pick this one up in any case.
>

I think that the OP means that you can't do single procedure compile
time bounds checking. Ie.

subroutine foo(x)
  real :: x(1)

  print *, x(2)
end subroutine foo(x)

A compiler would be quite justified in barfing at compile time on this
code. If you treat x(1) as x(*), however, then you would need to look at
the actual argument either at run time or compile time to pick up an
error.

David

Relevant Pages

  • Re: Creating arrays using GENERICS
    ... According to the book I read by Schildt: "Arrays of specific generic ... using generics and just defining it like this: ... Generics are a compile time feature, and not a run time feature as I ...
    (comp.lang.java.programmer)
  • Re: How does the intrinsic present work?
    ... > different versions of the subroutine. ... How can it, in general, be evaluated at compile time? ... separate compilation of program units, so if the subroutine is, for example, ...
    (comp.lang.fortran)
  • Re: use strict problem with command line argument?
    ... Jeff Pang wrote: ... This is called compile time. ... Everything else, that is not part of a subroutine, is executed. ...
    (perl.beginners)
  • allocatable vs non-allocatable arrays
    ... If I use the first version, I can compile and run it both with an allocatable and a non-allocatable actual argument. ... I can make sure it works correctly by checking the allocation status of the array. ... If I decided to make all arrays allocatable inside my library, I would reach maximum robustness, but I'd impose on the person using the library that she'd have to make all her arrays allocatable as well. ... end subroutine test ...
    (comp.lang.fortran)
  • Re: creaping coupling......
    ... In C++ it would be trivial to break that source code dependency, ... When you compile a .java module, ... In Java and C# it's asserted at compile time. ...
    (comp.object)