Home > Archive > Fortran > December 2004 > Re: g95 wish list
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Andy Vaught 2004-11-26, 4:09 pm |
| 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?
> 2. A switch for quad precision would be nice. The Lahey compiler provides
> this. Since it runs on low-end hardware, I suppose it is all done in
> software. If I can get my answer by flipping a switch and perhaps running
> overnight, that beats rewriting the code. And if I do have to rewrite the
> code, it is nice to know whether the failure is due to roundoff (change the
> algorithm or pick a simpler problem) or due some bug that may be easily
> fixed.
G95 will support a REAL*10 type corresponding to the x87 temporary real
on x86 hardware, including IA64 and x86_64. A software quad precision
type will also be supported.
Andy
| |
| Richard Maine 2004-11-26, 4:09 pm |
| Andy Vaught <andy@firstinter.net> writes:
> On Fri, 5 Nov 2004, Charles Russell wrote:
>
>
> 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.
--
Richard Maine
email: my last name at domain
domain: summertriangle dot net
| |
| Charles Russell 2004-11-26, 4:09 pm |
|
"Richard Maine" wrote
..>Such
> arrays exist.
Maybe so, but I haven't seen an example. In the code I have used from
netlib, dimension x(1) invariably means dimension x(*). And my chief
concern is with netlib code.
| |
| Richard Maine 2004-11-27, 3:57 pm |
| "Charles Russell" <STOPworworSPAM@bellsouth.net> writes:
> "Richard Maine" wrote
> .>Such arrays [with dimensions of 1] exist.
>
> Maybe so, but I haven't seen an example. In the code I have used from
> netlib, dimension x(1) invariably means dimension x(*). And my chief
> concern is with netlib code.
But I have seen examples. Someone briefly alluded to cases where
it comes up (sorry, but I don't have that post handy to attribute
properly). Auto-generation of code (including simple cases such
as macro substitution) is a prime way. And I have quite a lot of
cases where there is a general subroutine that takes an array of
something, but some particular calls only have one such item;
I've also fixed other people's code when they made the actual
argument a scalar in cases like that, and then discovered that
some compilers caught the error. (It is illegal.)
I can even imagine quite plausible cases where bounds violations
would occur only in cases of size 1; it would be nice to be able
to get help in finding them. I've seen codes that start out by
assuming there are at least 2 elements, where the 1-element case
would need special-casing; not very unusual, actually.
Your chief concern might be netlib, (and I'm certainly not implying
that you are alone) but I don't think that is a very good reason to
force the decision on everyone else.
If there can be a command-line switch, then fine. I've seen such
switches for this purpose, so they are certainly possible in general.
(The fact that vendors have done such switches suggests that they
have also seen codes on both sides).
But if it has to be one way and one way only, then I don't think that
old netlib code should be allowed to kill the capability of using
bounds checking on some new codes.
After all, it isn't like it is very difficult to fix the old code
in this case. The only thing that makes it nontrivial is the
possibility that there might be some of that code that you haven't seen.
And you can always just turn off the bounds checking in the netlib
code anyway. It tends to already be pretty well debugged. Of
course, one can (and people do) mess it up by errors in calling it,
but the main effect of the dimension 1 hack is to turn off bounds
checking anyway.
On the other hand, changing dimensions that really are 1 to
do something else can be quite difficult... not to speak of
unnatural. Imagine trying to eplxain to someone that they
should avoid using a size of 1 where that's what turns out to
be natural, and that the reason is because other code uses 1 when
it doesn't really mean it, so they should avoid using it when they
do. :-(
All of which is probably moot because a command-line switch is the
"obvious" way to do this.
--
Richard Maine
email: my last name at domain
domain: summertriangle dot net
| |
| Charles Russell 2004-11-29, 4:07 pm |
|
"Richard Maine" wrote
> Your chief concern might be netlib, (and I'm certainly not implying
> that you are alone) but I don't think that is a very good reason to
> force the decision on everyone else.
>
> If there can be a command-line switch, then fine.
Agreed.
> After all, it isn't like it is very difficult to fix the old code
> in this case.
It is a tedious pain in the ***. You fix a few instances, run again, and
get hung up on the next one. Significant programming overhead for the
casual user, plus the risk that a typo or outright blunder may introduce a
bug.
> All of which is probably moot because a command-line switch is the
> "obvious" way to do this.
Yes. But my fear is that in the enthusiasm for new features, backward
compatibility will get short shrift. So I'm the squeaky wheel. After all, a
public domain compiler should support public domain code. (Though we will
take what we can get, and be thankful.)
| |
| glen herrmannsfeldt 2004-11-29, 4:07 pm |
| Richard Maine wrote:
> "Charles Russell" <STOPworworSPAM@bellsouth.net> writes:
[color=darkred]
[color=darkred]
Just to be sure, we are talking about dummy arguments only.
(Of course they could be passed to a subroutine, but that
subroutine could use (*) or even the F66 standard variable
dimension form.)
[color=darkred]
> But I have seen examples. Someone briefly alluded to cases where
> it comes up (sorry, but I don't have that post handy to attribute
> properly). Auto-generation of code (including simple cases such
> as macro substitution) is a prime way. And I have quite a lot of
> cases where there is a general subroutine that takes an array of
> something, but some particular calls only have one such item;
There could about as easily be cases where the dimension
is zero, which I believe is illegal, or at least was in
earlier standards. It is legal in Java, and fairly useful
there, too. Maybe the most common case is command line arguments,
which are an array of strings, so no arguments is a String
array dimensioned zero.
> I've also fixed other people's code when they made the actual
> argument a scalar in cases like that, and then discovered that
> some compilers caught the error. (It is illegal.)
A almost thought I remembered it as legal, but I might
be remembering writing and reading from unformatted files,
where I do believe it is legal.
I am pretty sure it is legal to pass an array element as
an argument and reference other elements of the array,
with the passed element as the starting point, and it
is presumably legal to pass an array element to a scalar
argument. I do have to agree that those two combinations
don't guarantee the ability to pass a scalar to a subroutine
expecting an array, though.
> I can even imagine quite plausible cases where bounds violations
> would occur only in cases of size 1; it would be nice to be able
> to get help in finding them. I've seen codes that start out by
> assuming there are at least 2 elements, where the 1-element case
> would need special-casing; not very unusual, actually.
Most of the uses I think of would not be dummy variables,
which is the only case of concern. The only one I remember
actually doing was as a variable format in F66 days. It is
required to be an array, and I made it REAL*8 so I could
assign to it in one assignment without a loop.
> Your chief concern might be netlib, (and I'm certainly not implying
> that you are alone) but I don't think that is a very good reason to
> force the decision on everyone else.
Well, there is a lot of netlib code. It might be a large
fraction of the publicly available Fortran code.
> If there can be a command-line switch, then fine. I've seen such
> switches for this purpose, so they are certainly possible in general.
> (The fact that vendors have done such switches suggests that they
> have also seen codes on both sides).
> But if it has to be one way and one way only, then I don't think that
> old netlib code should be allowed to kill the capability of using
> bounds checking on some new codes.
Assuming the old code is all fixed format, and new code is
free format, would it be too much to only allow bounds
checking on dimension one dummies for free format?
-- glen
| |
| Carlie J. Coats 2004-11-29, 4:07 pm |
| Charles Russell wrote:
> "Richard Maine" wrote
>
> .>Such
>
>
>
> Maybe so, but I haven't seen an example. In the code I have used from
> netlib, dimension x(1) invariably means dimension x(*). And my chief
> concern is with netlib code.
You will find them all over the place with the MM5 meteorology model:
the design is to have a common code base that supports many different
types of (for example) moist microphysics that have different
requirements for what state-variable arrays are present. And since
memory footprint is historicaly a large concern, arrays are either
dimensioned (1) or dimensioned for the full grid, depending upon
whether they are active for that particular microphysics option.
You then wind up with things like
IF (IMPHYS.EQ.6 ) THEN
<something about QG and QNC>
END IF
Butt-ugly, INMHO, but it is a very widely used code (probably the
most widely-used met code there is, world-wide).
--
Carlie J. Coats, Jr. carlie.coats@baronams.com
Environmental Modeling Center carlie_coats@ncsu.edu
c/o North Carolina State University MEAS Department
1125 Jordan Hall Campus Box 8208
Raleigh, NC 27695 phone: (919)515-7076 / fax: (919)515-7802
"My opinions are my own, and I've got *lots* of them!"
| |
| glen herrmannsfeldt 2004-11-29, 4:07 pm |
| Carlie J. Coats wrote:
(someone wrote)
[color=darkred]
> You will find them all over the place with the MM5 meteorology model:
> the design is to have a common code base that supports many different
> types of (for example) moist microphysics that have different
> requirements for what state-variable arrays are present.
Just to be sure, the arrays in question are all subroutine
dummy variables. A compiler certainly knows the difference,
and can allocate a real dimension one array for the other case.
-- glen
| |
| Richard E Maine 2004-11-29, 4:07 pm |
| glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> There could about as easily be cases where the dimension
> is zero, which I believe is illegal, or at least was in
> earlier standards.
Perfectly legal in f90 and afterwards. Also, though it might
seem silly at first, it is also quite useful. I use them a lot.
Most often for dynamically-sized arrays, which might happen to
be size zero for some runs, but not others. Also as the initial
state for dynamically-grown arrays. On rare occasion, even
as a static array declaration.
One of the small new features in f2003 is that it is now much simpler
to write a zero-sized array constructor. Used to be that you had
to "fake" it with a zero-trip-count implied do. In f2003, you
can do something like
[real:: ]
which is a zero-sized array of reals. The "real::" part of the syntax
was added for other purposes, but it happens to also have this as
a degenerate, but useful case.
F90 also allows zero-length strings (f77 didn't), which are
similarly useful. I used to have to special-case zero-length
strings in my f77 codes. Happens all the time in parsing
inputs.
I regard the zero-sized arrays and zero-length strings as similar
to zero-trip DO loops. All are far more useful than might be
thought at first glance.
>
> A almost thought I remembered it as legal,
Nope. No way. Except for the one qurky case that is legal, but it is
a holdover from f77 and earlier days where the language didn't have
much array functionality and there were fundamental differences in the
descriptive mechanism. One of those descriptive differences persists
as a strange special case for compatibility. In f77, and array
element was a separate category of "thing". You could have an array
element as an actual argument... but not a scalar. An array element
didn't count as a scalar. Well, in f90, an array element counts as a
scalar in most contexts... but is allowed here with the special
meaning. (You allude to that special case in a para that I elided).
> but I might
> be remembering writing and reading from unformatted files,
> where I do believe it is legal.
Yes. That's a very different matter.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Charles Russell 2004-11-29, 8:57 pm |
|
"Richard E Maine" wrote
> In f77, and array
> element was a separate category of "thing". You could have an array
> element as an actual argument... but not a scalar. An array element
> didn't count as a scalar.
I'm lost but curious. Is there a simple example?
| |
| Richard E Maine 2004-11-29, 8:57 pm |
| "Charles Russell" <STOPworworSPAM@bellsouth.net> writes:
> "Richard E Maine" wrote
>
>
> I'm lost but curious. Is there a simple example?
Of an array element not counting as a scalar?... No. It is endemic
throughout the whole f77 (and earlier) standard. The simplest way
to point it out is in the definitions. There isn't even a definition
of the term "scalar" because it isn't needed. Everything is scalar...
well, except for arrays, and everything about arrays is a
special case. Note that an array isn't a variable in f77. (Nor is
an array element).
This results in many occcurances of phrases like "a variable or array
element" because there are lots of places where either is allowed.
But there are a few places where it is just "variable"; array
elements are not allowed even though they might make sense (and
are allowed in f90). Arrays (as opposed to elements) are allowed
only in a very few places really; all of them are specfically
listed.
And there is one place where an array element is allowed, but a
"variable" is not. This is as an actual argument corresponding
to an array dummy. If that's what you wanted an example of,
I'm sure (well, fairly sure) that it is a practice you have at
least seen, even if you don't think of it that way or know about
all its quirks. Such things as
program main
real x(10,10)
...
call sub(x(1,5))
end
subroutine sub (y)
real y(*)
...
end
That's how you would get the effect of passing a "slice" of
x as an actual argument to y. In particular, this example
would be how one would pass the 5th column of x.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Gordon Sande 2004-11-29, 8:57 pm |
|
Charles Russell wrote:
> "Richard E Maine" wrote
>
>
>
>
> I'm lost but curious. Is there a simple example?
>
Some folks call it a "partial array". It corresponds to the F90
x(i:)
to mean the elements i, i+1, i+2, ...
In F77
real x (10)
....
call sam ( x(6) )
so that sam has access to x(6), x(7), ...
>
| |
| Charles Russell 2004-11-29, 8:57 pm |
|
"Richard E Maine" wrote >>
>
> Of an array element not counting as a scalar?... No. It is endemic
> throughout the whole f77 (and earlier) standard.
I understand the example (I think) but not what you are saying about it. I
view the example as a simple consequence of pass-by-reference and columnwise
storage. I do not care how the compiler actually implements this, as long
as the results are the same. I think this is now called "storage
association."
Am I missing some subtle principle that might entrap the unwary f77 user?
| |
| glen herrmannsfeldt 2004-11-29, 8:57 pm |
|
Charles Russell wrote:
> "Richard E Maine" wrote >>
[color=darkred]
[color=darkred]
> I understand the example (I think) but not what you are saying about it. I
> view the example as a simple consequence of pass-by-reference and columnwise
> storage. I do not care how the compiler actually implements this, as long
> as the results are the same. I think this is now called "storage
> association."
Consider that you can pass an array element to a scalar dummy,
also as ordinary pass-by-reference. So why wouldn't passing a
scalar to an array dummy work, too? Because the standard doesn't
say that it must. (Most likely it will, though.)
As to the difference between array elements and scalars other
than as subroutine parameters, in F66 array elements were not
allowed as DO parameters, only constants or INTEGER scalar
variables. In I/O list for WRITE statements, scalar variables,
array elements and arrays are allowed, but not constants.
For F66 variable FORMATs, only arrays, not scalars, array
elements, or constants are allowed.
Note that in C the close association between arrays and pointers
does allow passing (the address of) a scalar when an array is
expected. (In this case, dummy arguments are always pointers
and not arrays.)
-- glen
| |
| Richard E Maine 2004-11-29, 8:57 pm |
| "Charles Russell" <STOPworworSPAM@bellsouth.net> writes:
> "Richard E Maine" wrote >>
>
> I understand the example (I think) but not what you are saying about it. I
> view the example as a simple consequence of pass-by-reference...
You may view it that way, but that is *NOT* what the standard
specifies. The standard does not, and never has, specified
pass-by-reference. Nor have all compilers implemented things that
way, even if you restrict yourself to "old" compilers. If you just
assume that it does, you will get things wrong - lots of them.
One of the more trivial things that you will get wrong is that you
will suppose that it will always work to pass a scalar actual
argument to an array dummy of size 1. It isn't legal and there
are compilers that will refuse to compile it. I've seen that. Heck,
I've even accidentally run into it in my own old f77 code.
If you want explanations based on your assumption that everything
is pass-by-reference, you'll have to ask someone else. I can't
explain the distinctions on that basis.
It is true that this feature happens to be trivial to implement with
pass-by-reference. Namely, it would "just work" if you did nothing
special. But you aren't going to understand the distinctions between
the caes that are standard and the ones that aren't on that basis.
> Am I missing some subtle principle that might entrap the unwary f77 user?
Yes. See above. Assumptions about pass-by-reference can and do trap
f77 users, even wary ones at times. It has trapped me in the past,
and I've helped other people who have also been trapped. If you think
the matter is purely academic, then you are fortunate that it hasn't yet
trapped you (that you know of).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| glen herrmannsfeldt 2004-11-29, 8:57 pm |
|
Richard E Maine wrote:
(snip)
> You may view it that way, but that is *NOT* what the standard
> specifies. The standard does not, and never has, specified
> pass-by-reference. Nor have all compilers implemented things that
> way, even if you restrict yourself to "old" compilers. If you just
> assume that it does, you will get things wrong - lots of them.
> One of the more trivial things that you will get wrong is that you
> will suppose that it will always work to pass a scalar actual
> argument to an array dummy of size 1. It isn't legal and there
> are compilers that will refuse to compile it. I've seen that. Heck,
> I've even accidentally run into it in my own old f77 code.
Another example discussed here some time ago, is the way the VAX/VMS
Fortran compiler did character (apostrophed) string constants.
CHARACTER variables should be passed by descriptor according to
the VAX/VMS calling convention, but F66 code passed string constants
to ordinary arrays, where a string descriptor wouldn't work.
It seems that he solution was to have the linker recognize at link
time if the dummy argement was a CHARACTER variable or not, and
fix the calling argument list appropriately. Very strange.
-- glen
| |
| Richard E Maine 2004-11-30, 4:02 pm |
| Catherine Rees Lay <spamtrap@polyhedron.org.uk> writes:
> 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).
Yes, there are some. But in my experience, they are the exceptions.
Maybe more compilers do that recently - I haven't kept track.
> 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.
Actually, that's legal. But then you aren't supposed to be able to
reference any but the first element. That's a case where the bounds
check should, and trivially can properly catch it for x(1), but should
not for x(*).
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Richard E Maine 2004-12-03, 3:59 pm |
| Catherine Rees Lay <spamtrap@polyhedron.org.uk> writes:
> Well, granted. But in real code, how much use is this anyway? Surely
> the type of array subscript which goes out-of-bounds is almost always
> either a variable or an expression which can't be evaluated at
> compile-time?
I don't think I'll try to estimate the relative frequency of bounds
problems. I will just say that I hesitate to say that any kind of
error doesn't happen. On this one in particular, though I can't
comment on frequency very precisely, it is apparently frequent enough
for me to have seen it happen. I won't say I've seen it a lot, but I
have seen it.
1. I have seen compilers reject code exactly like that. Multiple compilers.
And there wasn't even an option to tell it to ignore the error. The
code simply would not compile until it was fixed. This very specifically
includes some of that venerable netlib code using (1) as a hack for (*).
I just did the trivial fix with a monitored global search&replace
in my editor. Wasn't a very big deal to fix.
2. I have also seen bounds errors in compile-time expressions like that.
In fact, I've specifically seen bounds errors in referencing element
2 of an array, which only had 1 element. That's an array that
actually had only one element, not just a dummy that looks like it.
It isn't unusual for some kinds of algorithms to start out assuming
that there are at least 2 elements and hard-wire rreeferences to
elements 1 and 2. The 1-element case can still be meaningful,
but need special treatment. You take a general algorithm like
that, coded without the specisl-case handling, and use it on one
of those special cases, and you have a bounds error.
> And also, if I was editing or debugging an old routine which used (1)
> instead of (*), the very first thing I would do would be to change it
> to use *.
Me too. particularly if it took that to make the compiler accept it. :-)
See item 1 above.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| Dr Chaos 2004-12-13, 9:01 pm |
| Charles Russell wrote:
> "Richard Maine" wrote
>
> .>Such
>
>
>
> Maybe so, but I haven't seen an example. In the code I have used from
> netlib, dimension x(1) invariably means dimension x(*). And my chief
> concern is with netlib code.
>
>
I have found that a fair chunk of the old code stored at www.netlib.org
which has anachronisms like x(1) instead of x(*) has been replicated,
and made legal Fortran 77 as part of SLATEC, also at www.netlib.org
| |
| Charles Russell 2004-12-14, 3:57 am |
|
"Dr Chaos" wrote
>
> I have found that a fair chunk of the old code stored at www.netlib.org
> which has anachronisms like x(1) instead of x(*) has been replicated,
> and made legal Fortran 77 as part of SLATEC, also at www.netlib.org
>
Thanks for the suggestion. My habit is to look first to my own collection
of familiar old code, and I hadn't thought of looking for updates in SLATEC.
I suppose CMLIB3, found on statlib, might also be worth a look. But I would
still prefer an f95 compiler that retains all the options to support old
code that are found in a typical mature f77 compiler.
|
|
|
|
|