From: glen herrmannsfeldt on 20 Oct 2009 15:14 cjpsimon(a)gmail.com <cjpsimon(a)gmail.com> wrote: > When I compile with gfortran (gcc 4.4) this fragment of code alone : > file : test.f90 > Subroutine getpar (par, amax) > Integer par(amax) > Integer amax > End (snip) > Error: Symbol 'amax' at (1) already has basic type of REAL Have you tried with names other than amax? Maybe bmax or cmax? As others have said, it is an ordering problem, but this case is especially hard for the compiler, amax being an intrinsic function with type REAL. (I don't know that it would be any better to use an intrinsic INTEGER function name.) It IS legal, but sometimes confusing (to both people and compilers), to use such names for variables. -- glen
From: Richard Maine on 20 Oct 2009 15:25 glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: > amax being an intrinsic function with type REAL. It is? I suppose I might have missed it, as I don't use the several strangely named f66 remnants of the max and min intrinsics. But a quick skim fails to find an intrinsic of any such name. There are amax0 and amax1, but I don't know of an amax without the digit suffix. (And, of course, there is max, without the "a"). Willing to believe I might have missed it. -- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on 20 Oct 2009 16:00 Richard Maine <nospam(a)see.signature> wrote: > glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote: >> amax being an intrinsic function with type REAL. > It is? I suppose I might have missed it, as I don't use the several > strangely named f66 remnants of the max and min intrinsics. But a quick > skim fails to find an intrinsic of any such name. There are amax0 and > amax1, but I don't know of an amax without the digit suffix. (And, of > course, there is max, without the "a"). Willing to believe I might have > missed it. Yes, I looked it up right after posting. I was remembering the AMAX0 and AMAX1, and assuming that there would be a generic AMAX. Still, it might confuse some compilers, or some readers. -- glen
From: cjpsimon on 20 Oct 2009 17:21 On 20 oct, 22:00, glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > Richard Maine <nos...(a)see.signature> wrote: > > glen herrmannsfeldt <g...(a)ugcs.caltech.edu> wrote: > >> amax being an intrinsic function with type REAL. > > It is? I suppose I might have missed it, as I don't use the several > > strangely named f66 remnants of the max and min intrinsics. But a quick > > skim fails to find an intrinsic of any such name. There are amax0 and > > amax1, but I don't know of an amax without the digit suffix. (And, of > > course, there is max, without the "a"). Willing to believe I might have > > missed it. > > Yes, I looked it up right after posting. I was remembering the AMAX0 > and AMAX1, and assuming that there would be a generic AMAX. > > Still, it might confuse some compilers, or some readers. > > -- glen That was one thing I was thinking of. amax as an intrinsic function of type REAL, remembering the fortran IV days... But beginning with "a", it may be of an implicit type REAL... I am not sure what is driving the compiler in error detection in this case or just the noticed rule in paragraph 7.1.6 ?. May I must always add -std=f95 or -pedantic as an option for gfortran to detect extensions use. My need is portability and all I want is to minimize the work in using others compilers. Thank you all for remembering me the simple rule of ordering declaration statements.
From: steve on 20 Oct 2009 17:44
On Oct 20, 2:21 pm, "cjpsi...(a)gmail.com" <cjpsi...(a)gmail.com> wrote: > case or just the noticed rule in paragraph 7.1.6 ?. May I must always > add -std=f95 > or -pedantic as an option for gfortran to detect extensions use. > -std=f95 and -std=f2003 can be used to increase gfortran's adherence to these standards. Most (if not all) extensions should be flagged. However, there are probably ways to trick the compiler into doing something that in non-conforming, and as always there are the ever present processor- dependent choices. Other options that might help write cleaner code are -Wall and - Wsurprising. |