- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The F-95 standard requires that functions appearing in specification expressions should return scalar integer results.
but since many F-95 intrinsic functions, such as count(), can return scalars or arrays depending on their arguments (eg, count(x,dim=1)), this can be a bit difficult to check.
Eg, is the function below fully compliant?
============
pure function tfunc(mask)
implicit none
logical,intent(in)::mask(:)
integer,dimension(count(mask))::tfunc
....
==============
the specification expression is always scalar in this specific case, but what about
============
pure function tfunc(mask)
implicit none
logical,intent(in)::mask(:,:)
integer,dimension(count(mask))::tfunc
....
==============
where the result of count is scalar only because the dim argument is omitted...
thanks in advance for any clarification of this,
dmitri
but since many F-95 intrinsic functions, such as count(), can return scalars or arrays depending on their arguments (eg, count(x,dim=1)), this can be a bit difficult to check.
Eg, is the function below fully compliant?
============
pure function tfunc(mask)
implicit none
logical,intent(in)::mask(:)
integer,dimension(count(mask))::tfunc
....
==============
the specification expression is always scalar in this specific case, but what about
============
pure function tfunc(mask)
implicit none
logical,intent(in)::mask(:,:)
integer,dimension(count(mask))::tfunc
....
==============
where the result of count is scalar only because the dim argument is omitted...
thanks in advance for any clarification of this,
dmitri
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The first function is fully compliant.
The second one is too because DIM is omitted. You know that. If you add DIM then it would not be compliant and our compiler complains. I don't see why this is "hard to check". The compiler always knows what the rank of MASK is. If MASK is rank 1, then DIM is ok to be specified, otherwise it is not.
It would be truly hard if DIM in this case was allowed to be a dummy argument that is OPTIONAL (a general concept that has given us fits in the past), but this combination is prohibited in a specification expression.
The second one is too because DIM is omitted. You know that. If you add DIM then it would not be compliant and our compiler complains. I don't see why this is "hard to check". The compiler always knows what the rank of MASK is. If MASK is rank 1, then DIM is ok to be specified, otherwise it is not.
It would be truly hard if DIM in this case was allowed to be a dummy argument that is OPTIONAL (a general concept that has given us fits in the past), but this combination is prohibited in a specification expression.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks for the fast replies Steve. Indeed I used "a bit difficult" rather than "difficult" since, being unfamiliar with compiler writing, I dont know whether these kind of checks are trivial/routine in compiler language. Clearly this other compiler I tried using found it difficult enough ... thankfully the intel compiler does this correctly and (presumably) easily :-).

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page