Prev: Problem with automatic reallocation of allocatable scalar on assignment
Next: a wiki entry for gfortran
From: Terence on 13 Aug 2010 19:19
On Aug 14, 1:16 am, nos...(a)see.signature (Richard Maine) wrote:
> Terence <tbwri...(a)cantv.net> wrote:
> > My compiler has no objection to this, since only pointers to memory
> > are passed, and the compilation and linking is error-free, but the
> > OP's G77 points out that the workspace variables passed to the
> > routines vary by type from call to call and therfore gives compiling
> > problems.
>
> Are these "compiling problems" errors or warnings? Showing the exact
> error message would be helpful. In my experience, although such code is
> nonstandard, the large majority of compilers will accept it with no
> worse than a warning. I thought that included g77, though I don't have a
> copy handy to check. It it generates warnings, then that is appropriate.
> You can either ignore them, see if there is a way to turn them off, or
> fix the code. Fixing the code would require more substantial surgery.
>
> > Another two problem areas are , where
> > SUBORD is defined as
> >      REAL SUBORD(1):-
>
> > But exceeding the array size of (1), fairly common usage if you don'r
> > know the maximunm array size...
>
> It was common practice in f66, where there were no other good
> alternatives short of passing the array size. However, it has never been
> standard conforming, even in f66. In f77, the correct solution is to use
> assumed size (that is dimension the dummy arrays as * instead of 1).
> That's exactly what assumed size is for and what it means.
>
> Do note that the messages you quoted are all warnings - not errors. One
> should be conscious of the diference. WIth an error, the code will not
> work and an object file is usually not even made. WIth a warning, an
> object file is produced and the code might well work correctly, as it
> wil in these cases. The compiler is just warning you that something is
> questionable. The compiler is correct here.
>
> If you really want to eliminate all warnings from f66-style code, then
> laudable as that might be in some sense, you are likely to have a harder
> job. I was assuming you just wanted to make the code work.
>
> You are lucky that the compiler only made this a warning. I have used
> compilers where it was an error and the code woul dnot run until it was
> fixed. Fortunately, the fix of changing the 1 to a * is easy here, even
> if you need to do it a few dozen times. If there are many more than
> that, it can get to be a pain and require some parsing because you don't
> want to blindly change every appearance in the code of (1) TO (*).
>
> > And more strangely (only the precise element number is objected to):-
>
> That's quite typical. Only when you use constant expressions can the
> compiler easily detect the problem at compilation time.
>
> --
> Richard Maine                    | Good judgment comes from experience;
> email: last name at domain . net | experience comes from bad judgment.
> domain: summertriangle           |  -- Mark Twain

Thanks for the reminder of (*).
I don't think I ever used it, since my compiler accepts (1) as the
equivalent.
However I did locate that SUBORD(5) should have been used and written,
but only A(*) solves the other case.
One responder has just requested copies of original, data and
expected output; I hope to see a different attack on this. I supplied
my own version as well to save a lot of hard work already done in
vital areas.
First  |  Prev  | 
Pages: 7 8 9 10 11 12 13 14 15 16 17
Prev: Problem with automatic reallocation of allocatable scalar on assignment
Next: a wiki entry for gfortran