"Class array A must be a pointer, allocatable or assumed-shape"

[Thomas Koenig]

Is the following program legal?

module buggy
implicit none
type :: bar
integer :: x
end type bar
type :: foo
integer :: n
contains
procedure :: fun1
end type foo
contains
subroutine fun1(this, a)
implicit none
class(foo) :: this
class(bar), intent(in) :: a(this%n)
end subroutine fun1
end module buggy

I ask because NAG rejects this with

Error: 92065.f90, line 15: CLASS array A must be a pointer,
allocatable or assumed-shape

which clearly a is not, but I cannot find anything in the standard
which says so (maybe I've been looking in the wrong places).

[John]

For what it is worth, compiles with ifort, nvfortran, and gfortran with no warnings. Other than "a" not being used in the fun1() procedure which should not be illegal anyway and I assume is just an artifact from making a reproducer I do not see anything unusual.

[Peter Klausler US]

C708 requires things declared as CLASS to be dummy arguments, pointers, or allocatables. But there's no proscription against explicit shape dummy arguments that I can find in Fortran 2018, and I looked at every instance of the phrases related to assumed shape and explicit shape. It might be an implementation limitation in NAG, since the type is coming in a descriptor but the bounds are not.

[Steve Lionel]

On 1/23/2021 8:05 AM, Thomas Koenig wrote:
> Is the following program legal?
>

snip

>
> I ask because NAG rejects this with
>
> Error: 92065.f90, line 15: CLASS array A must be a pointer,
> allocatable or assumed-shape
>
> which clearly a is not, but I cannot find anything in the standard
> which says so (maybe I've been looking in the wrong places).

I think it is legal, and have sent a note off to Malcolm to inquire. The
closest text in the standard I can find to the error message is (from
F2018, but the same words are in F2008 and F2003):

C708 An entity declared with the CLASS keyword shall be a dummy argument
or have the ALLOCATABLE or POINTER attribute.

Since A is a dummy argument, this doesn't apply.

--
Steve Lionel
ISO/IEC JTC1/SC22/WG5 (Fortran) Convenor
Retired Intel Fortran developer/support
Email: firstname at firstnamelastname dot com
Twitter: @DoctorFortran
LinkedIn: https://www.linkedin.com/in/stevelionel
Blog: https://stevelionel.com/drfortran
WG5: https://wg5-fortran.org

[Thomas Koenig]

Steve Lionel <st...@seesignature.invalid> schrieb:

> On 1/23/2021 8:05 AM, Thomas Koenig wrote:
>> Is the following program legal?
>>
> snip
>>
>> I ask because NAG rejects this with
>>
>> Error: 92065.f90, line 15: CLASS array A must be a pointer,
>> allocatable or assumed-shape
>>
>> which clearly a is not, but I cannot find anything in the standard
>> which says so (maybe I've been looking in the wrong places).
>
> I think it is legal, and have sent a note off to Malcolm to inquire. The
> closest text in the standard I can find to the error message is (from
> F2018, but the same words are in F2008 and F2003):
>
> C708 An entity declared with the CLASS keyword shall be a dummy argument
> or have the ALLOCATABLE or POINTER attribute.

> Since A is a dummy argument, this doesn't apply.

Thanks, then it is as I thought.

The reason I'm asking is that I am currently going through some
gfortran bug reports and checking the test cases against NAG,
for which they gave me a non-commercial license.

The usual assumption is that the NAG compiler will catch errors in
test cases that gfortran misses, or get things right that gfortran
doesn't, but occasionally, it is the other way around :-)

[Thomas Koenig]

Peter Klausler US <pkla...@nvidia.com> schrieb:

> C708 requires things declared as CLASS to be dummy arguments,
> pointers, or allocatables. But there's no proscription against
> explicit shape dummy arguments that I can find in Fortran 2018,
> and I looked at every instance of the phrases related to assumed
> shape and explicit shape.

That settles it, then.

>It might be an implementation limitation
> in NAG, since the type is coming in a descriptor but the bounds
> are not.

Probably something that is fixable - if a calling convention
is rejected, it is always possible to fix it with a different
calling convention :-)

[gah4]

But what does it mean?

Usual arrays in Fortran are of things that are known size at compile
time, or are references in some way to things stored somewhere else.

In Java, there are primitive types and references, such that everything
that isn't a primitive type is a reference (you aren't supposed to call
them pointers, but otherwise). Arrays are objects, such that N
dimensional arrays are actually N-1 dimensional arrays of array
references, and 1 dimensional arrays of the actual type.
There is no type that is an array of contiguously allocated things,
other than primitive types. (byte, char, short, int, long, float, double, boolean)

Maybe I don't understand Fortran class well enough, but it isn't so
obvious how arrays of them work.

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:

> On Sunday, January 24, 2021 at 1:53:38 AM UTC-8, Thomas Koenig wrote:
>> Peter Klausler US <pkla...@nvidia.com> schrieb:
>> > C708 requires things declared as CLASS to be dummy arguments,
>> > pointers, or allocatables. But there's no proscription against
>> > explicit shape dummy arguments that I can find in Fortran 2018,
>> > and I looked at every instance of the phrases related to assumed
>> > shape and explicit shape.
>
>> That settles it, then.
>
>> >It might be an implementation limitation
>> > in NAG, since the type is coming in a descriptor but the bounds
>> > are not.
>
>> Probably something that is fixable - if a calling convention
>> is rejected, it is always possible to fix it with a different
>> calling convention :-)
>
> But what does it mean?
>
> Usual arrays in Fortran are of things that are known size at compile
> time,

Not necessarily.

It is, for example, possible to have an array of characters
of length that is unknown at compile time. For example:

subroutine foo(a)
character(len=*), dimension(:) :: a
print *,len(a)
print *,size(a)
end subroutine foo

You can also have an allocatable array of characters:

character(len=:), dimension(:) :: b

and give it a length via an ALLOCATE statement.

>or are references in some way to things stored somewhere else.

It is not possible in Fortran to have an array of pointers. You can
have arrays of derived types which contain pointers.

> In Java, there are primitive types and references, such that everything
> that isn't a primitive type is a reference (you aren't supposed to call
> them pointers, but otherwise). Arrays are objects, such that N
> dimensional arrays are actually N-1 dimensional arrays of array
> references, and 1 dimensional arrays of the actual type.

That is a big difference to Fortran. An array is, in the words
of the standard (3.3), a

# set of scalar data, all of the same type and type parameters,
# whose individual elements are arranged in a rectangular pattern

> There is no type that is an array of contiguously allocated things,
> other than primitive types. (byte, char, short, int, long, float, double, boolean)

That is different to what Fortran does, as you can see from the above
definition.

> Maybe I don't understand Fortran class well enough, but it isn't so
> obvious how arrays of them work.

As written above, all elements of a Fortran array have the same
type.

Not knowing Java, I cannot really draw an analogy between Fortran
and Java. I suspect a Java class to be somewhat different from
a Fortran class. Just some points:

In Fortran, you declare a derived type. You can extend a derived
type, and you can bind procedures to it (which gives you type-bound
procedures).

If you declare a variable to be the class of the same type, it
means that that variable can be of the correspoding type, or of
some type that has extended the original type. However, you can
only declare class variables if they are pointers, allocatables
or dummy variables.

So, if you have

module x
type foo
integer :: i
end type foo
contains
subroutine bar(a)
class(foo), dimension(:) :: a

means that you can pass a 1d- array of type(foo) variables, or of
variables of a type that has been derived from type foo, to a.
All of elements have to have the same type.

[Ron Shepard]

On 1/24/21 10:53 AM, Thomas Koenig wrote:
[...]

> So, if you have
>
> module x
> type foo
> integer :: i
> end type foo
> contains
> subroutine bar(a)
> class(foo), dimension(:) :: a
>
> means that you can pass a 1d- array of type(foo) variables, or of
> variables of a type that has been derived from type foo, to a.
> All of elements have to have the same type.

I have a question related to class declarations. suppose your subroutine
takes two arguments

subroutine bar( a, b )
class(foo), dimension(:) :: a, b

Is there any way to declare those two dummy arguments so that

1) they must be of the same type, and

2) the compiler tells you at compile time if there is ever a
statement of the form

call bar( c, d )

where the actual arguments c and d are of different types.

I know that inside bar() you can have SELECT TYPE blocks that enforce
this at run time. What I'm asking rather is if there is a way to declare
the arguments so that this can be enforced at compile time instead.

If instead of class() declarations the subroutine had type()
declarations, then one could achieve this with a generic interface to
the various type-specific versions of the subroutine. Is there an
incantation that allows generic interfaces to subroutines with class()
dummy arguments that could achieve the compile-time testing ability?

$.02 -Ron Shepard

[gah4]

On Sunday, January 24, 2021 at 9:38:27 AM UTC-8, Ron Shepard wrote:
>
(snip)

> I have a question related to class declarations. suppose your subroutine
> takes two arguments

> subroutine bar( a, b )
> class(foo), dimension(:) :: a, b

> Is there any way to declare those two dummy arguments so that

> 1) they must be of the same type, and

> 2) the compiler tells you at compile time if there is ever a
> statement of the form

> call bar( c, d )

> where the actual arguments c and d are of different types.

> I know that inside bar() you can have SELECT TYPE blocks that enforce
> this at run time. What I'm asking rather is if there is a way to declare
> the arguments so that this can be enforced at compile time instead.

I mostly learned OO programming for Java, and am now trying (sometimes)
to back learn it to Fortran.

One of the important parts of OO is that you can use a subclass
where you could otherwise use the class, when you don't need the
added properties.

> If instead of class() declarations the subroutine had type()
> declarations, then one could achieve this with a generic interface to
> the various type-specific versions of the subroutine. Is there an
> incantation that allows generic interfaces to subroutines with class()
> dummy arguments that could achieve the compile-time testing ability?

I don't think so.

If you have a method:

void bar(foo a, foo b) ...

you can call it with values of class foo, or any subclass of foo.
This allows for extending classes retaining back compatibility.

Now add a new method:

void bar(foos a, foos b) ...

(personally, I never liked the foo and bar names, but otherwise)

where foos is a subclass of foo.

(Java doesn't have the complication of GENERIC. You just declare more
methods of the same name, and different arguments.)

A call with two foos will go to the new one, calls with one foo and one foos
to the original one. The original one should keep doing what it always did,
even though the arguments now have something more.

On the other hand, if you have methods:

void bar(foo a, foos b) ...
and
void bar(foos a, foo b) ...
but no method
void bar(foo a, foo b) ...

and you called it with two arguments of type foo, then it would
fail at compile time.

Since there are two that are equally right, and it fails uniqueness
at compile time.

[gah4]

On Sunday, January 24, 2021 at 8:53:14 AM UTC-8, Thomas Koenig wrote:

(snip, I wrote)

> > Usual arrays in Fortran are of things that are known size at compile
> > time,

> Not necessarily.

> It is, for example, possible to have an array of characters
> of length that is unknown at compile time. For example:

OK, but like variable dimension arrays back to Fortran 66,
all need to be the same size.

> subroutine foo(a)
> character(len=*), dimension(:) :: a
> print *,len(a)
> print *,size(a)
> end subroutine foo

> You can also have an allocatable array of characters:

> character(len=:), dimension(:) :: b

> and give it a length via an ALLOCATE statement.

But if you make an array of them, they all have the same length.

> >or are references in some way to things stored somewhere else.

> It is not possible in Fortran to have an array of pointers. You can
> have arrays of derived types which contain pointers.

or an array of derived types with ALLOCATABLE variables
inside, which also (somehow) reference memory somewhere else.

> > In Java, there are primitive types and references, such that everything
> > that isn't a primitive type is a reference (you aren't supposed to call
> > them pointers, but otherwise). Arrays are objects, such that N
> > dimensional arrays are actually N-1 dimensional arrays of array
> > references, and 1 dimensional arrays of the actual type.

> That is a big difference to Fortran. An array is, in the words
> of the standard (3.3), a

> # set of scalar data, all of the same type and type parameters,
> # whose individual elements are arranged in a rectangular pattern

Java arrays don't have that restriction. It is easy to allocate them
that way, though.

> > There is no type that is an array of contiguously allocated things,
> > other than primitive types. (byte, char, short, int, long, float, double, boolean)

> That is different to what Fortran does, as you can see from the above
> definition.

> > Maybe I don't understand Fortran class well enough, but it isn't so
> > obvious how arrays of them work.

> As written above, all elements of a Fortran array have the same
> type.

OK, so no arrays of class(*).

> Not knowing Java, I cannot really draw an analogy between Fortran
> and Java. I suspect a Java class to be somewhat different from
> a Fortran class. Just some points:

> In Fortran, you declare a derived type. You can extend a derived
> type, and you can bind procedures to it (which gives you type-bound
> procedures).

> If you declare a variable to be the class of the same type, it
> means that that variable can be of the correspoding type, or of
> some type that has extended the original type. However, you can
> only declare class variables if they are pointers, allocatables
> or dummy variables.

So dummy variables can be non-pointer, non-allocatable, but with
actual argument that is an array of one of those.

OK, I suppose that works ask well as CHARACTER*(*).

> So, if you have

> module x
> type foo
> integer :: i
> end type foo
> contains
> subroutine bar(a)
> class(foo), dimension(:) :: a

> means that you can pass a 1d- array of type(foo) variables, or of
> variables of a type that has been derived from type foo, to a.
> All of elements have to have the same type.

OK.

In Java, as with subarray lengths, you can have different types
in an array of references, as long as they are of the appropriate class,
or a subclass of it.

Most general is an array of Object, the superclass of all classes,
which can hold a reference to any reference (non primitive) type.

[Steve Lionel]

On 1/23/2021 5:49 PM, Steve Lionel wrote:
> On 1/23/2021 8:05 AM, Thomas Koenig wrote:
>> Is the following program legal?
>>
> snip

Malcolm responded:

"The code is (obviously?) technically valid, but I didn’t think it made
sense for non-assumed-shape dummies to be polymorphic, as they have to
be passed by dope vector not address anyway, and so I didn’t implement
it. No-one has ever complained!

So yes, this is a deficiency in the NAG compiler, but the burning
question is why use an old-style (F77) array-spec anyway? It gains
almost nothing in performance as the compiler doesn’t know the memory
stride but has to work it out from the dope vector. So you might as well
use assumed-shape and get all the usability advantages that brings.

If an actual customer complained, I’d get around to implementing it. But
it seems like poor style and a waste of effort (there’s lots of better
things we are busy adding)."

[Ev. Drikos]

On 23/01/2021 15:05, Thomas Koenig wrote:
> Is the following program legal?
>
>

> Error: 92065.f90, line 15: CLASS array A must be a pointer,
> allocatable or assumed-shape
>
> which clearly a is not, but I cannot find anything in the standard
> which says so (maybe I've been looking in the wrong places).
>

Oh, 92065 is a PR number. There is a more complex test case in the PR
that contains the following two arguments, also a reproducer I guess:

1. function linear_vector
class(*),intent(in):: a_VI(:,iMin:)

2. real function bilinear_scalar
class(*),intent(in):: a_II(iMin:,jMin:)

With or without POINTER attributes ie this PR would still have been
opened. Yet, I don't wonder why they use such upper/lower limits. I
guess they possibly had some reason, ie easier implementation or it's
already written why change it :-)

[Thomas Koenig]

Steve Lionel <st...@seesignature.invalid> schrieb:

> "The code is (obviously?) technically valid, but I didn’t think it made
> sense for non-assumed-shape dummies to be polymorphic, as they have to
> be passed by dope vector not address anyway, and so I didn’t implement
> it. No-one has ever complained!

The way the message is worded, it makes the user think that the
feature is actually not supported by the language, as opposed to
the compiler. If people don't dig into the standard, they will be
decieved into thinking that this is indeed illegal, expecially
for a compiler like nagfor which has a reputation for being very
standard-compliant.

In that case, it might make sense to put an "Sorry, unimplemented"
message in there and (possibly) issue an internal compiler error.
It's what gfortran does.

Personally, I'd think that would be much more user-friendly, but
who am I to prescribe what other compiler writers do :-)

> So yes, this is a deficiency in the NAG compiler, but the burning
> question is why use an old-style (F77) array-spec anyway?

In this particular question, the intent seemed to be pretty clear,
and it actually addresses a wider deficiency of assumed-shape arrays.

The extent of the array was self%n, so the writer apparently wanted
to specify the number of array elements as being the same as some
number in the class itself.

This touches on a point where assumed-shape arguments could be
improved, by the way.

With explicit-shape arguments, it is possible to write

subroutine foo(a,b,n)
integer :: n
real :: a(n), b(n)

and it is clear that the two arrays are of equal size.

For

subroutine foo(a,b)
real :: a(:), b(:)

it is not easy to specify that size(a) == size(b). It is possible
at runtime, but that incurs runtime overhead and is not checkable
by the caller at compile-time, so

call foo(a(1:3), b(1:4))

would go undetected.

> If an actual customer complained, I’d get around to implementing it. But
> it seems like poor style and a waste of effort (there’s lots of better
> things we are busy adding)."

I don't pay for nagfor, so I guess I don't count :-)

[Thomas Koenig]

gah4 <ga...@u.washington.edu> schrieb:

>> You can also have an allocatable array of characters:
>
>> character(len=:), dimension(:) :: b
>
>> and give it a length via an ALLOCATE statement.
>
> But if you make an array of them, they all have the same length.

Yes.

If you want to make an array of "strings", you can do it like this:

type string
character (len=:), allocatable :: s
end type string
type (string), dimension(:), allocatable :: a

and then allocate each of the strings separately (or use
allocation on assignment, like

a%s = 'foobar'

like you wrote here

> or an array of derived types with ALLOCATABLE variables
> inside, which also (somehow) reference memory somewhere else.

>> # set of scalar data, all of the same type and type parameters,
>> # whose individual elements are arranged in a rectangular pattern
>
> Java arrays don't have that restriction. It is easy to allocate them
> that way, though.

For optimization purposes, this is actually quite good. There are
a lot of techniques which rely on strides between elements being
constant. You can also do a C-style pointer forest, if you want to,
of course.

>> As written above, all elements of a Fortran array have the same
>> type.
>
> OK, so no arrays of class(*).

Again, you can do it, but all elements of the array have to
be of the same type.

[Robin Vowels]

On Sunday, January 24, 2021 at 10:32:28 PM UTC+11, gah4 wrote:
> On Sunday, January 24, 2021 at 1:53:38 AM UTC-8, Thomas Koenig wrote:
> > Peter Klausler US <pkla...@nvidia.com> schrieb:
> > > C708 requires things declared as CLASS to be dummy arguments,
> > > pointers, or allocatables. But there's no proscription against
> > > explicit shape dummy arguments that I can find in Fortran 2018,
> > > and I looked at every instance of the phrases related to assumed
> > > shape and explicit shape.
>
> > That settles it, then.
>
> > >It might be an implementation limitation
> > > in NAG, since the type is coming in a descriptor but the bounds
> > > are not.
>
> > Probably something that is fixable - if a calling convention
> > is rejected, it is always possible to fix it with a different
> > calling convention :-)
> But what does it mean?
>
> Usual arrays in Fortran are of things that are known size at compile
> time,

.
Not so.
Most arrays are dynamic, i.e., their size is not known until
execution time.
Arrays became dynamic from F90 (in addition to fixed size
arrays that existed until then).
Dynamic arrays mean that algorithms (in the true sense of the word)
can be written. Such arrays are required in much scientific work,
and include such non-scientific work as sorting.
.
The need for dynamic arrays has existed from the 1950s,
and was supported in Algol 60 and PL/I (1966).
Dynamic arrays were available in 1955 in the GIP scheme
available on the Pilot ACE and English Electric DEUCE.
.

[Robin Vowels]

On Monday, January 25, 2021 at 5:40:57 AM UTC+11, gah4 wrote:
> On Sunday, January 24, 2021 at 8:53:14 AM UTC-8, Thomas Koenig wrote:
>
> (snip, I wrote)
> > > Usual arrays in Fortran are of things that are known size at compile
> > > time,
>
> > Not necessarily.
>
> > It is, for example, possible to have an array of characters
> > of length that is unknown at compile time. For example:

.

> OK, but like variable dimension arrays back to Fortran 66,

.
FORTRAN before F90 had "adjustable dimensions",
not variable dimensions.
.

[Robin Vowels]

.
What?
Bounds of arrays are available by other means.
.

> and it is clear that the two arrays are of equal size.

.
subroutine foo (a, b)

real :: a(:), b(:)

if (size(a) /= size(b)) then ...
also makes it clear.

.
> For
>
> subroutine foo(a,b)
> real :: a(:), b(:)
>
> it is not easy to specify that size(a) == size(b).

.
What?
Try IF (SIZE(A) == SIZE(B)) THEN ...

.
> It is possible at runtime,

.
Of course it is.
.

> but that incurs runtime overhead

.
Naturally, but the overhead is small, and probably trivial.
.

> and is not checkable
> by the caller at compile-time, so
>
> call foo(a(1:3), b(1:4))
>
> would go undetected.

.
Not if the subroutine does the check.

[Ron Shepard]

On 1/24/21 7:20 PM, Steve Lionel wrote:
> On 1/23/2021 5:49 PM, Steve Lionel wrote:
>> On 1/23/2021 8:05 AM, Thomas Koenig wrote:
>>> Is the following program legal?
>>>
>> snip
>
> Malcolm responded:
>
> "The code is (obviously?) technically valid, but I didn’t think it made
> sense for non-assumed-shape dummies to be polymorphic, as they have to
> be passed by dope vector not address anyway, and so I didn’t implement
> it. No-one has ever complained!
>
> So yes, this is a deficiency in the NAG compiler, but the burning
> question is why use an old-style (F77) array-spec anyway? It gains
> almost nothing in performance as the compiler doesn’t know the memory
> stride but has to work it out from the dope vector. So you might as well
> use assumed-shape and get all the usability advantages that brings.

For normal arrays, explicit shape dummy arrays are contiguous, while
assumed shape dummy arrays can be associated with array slices and
strides and so on. That is important when sequence association is used
somehow, e.g. to map a 1-D actual argument to a 2-D dummy argument. That
sometime trips copy-in/copy-out argument association rather than the
simpler association by base address. Does that also apply to polymorphic
class() arrays?

$.02 -Ron Shepard

[gah4]

On Monday, January 25, 2021 at 1:33:51 AM UTC-8, Ron Shepard wrote:

(snip)

> For normal arrays, explicit shape dummy arrays are contiguous, while
> assumed shape dummy arrays can be associated with array slices and
> strides and so on. That is important when sequence association is used
> somehow, e.g. to map a 1-D actual argument to a 2-D dummy argument. That
> sometime trips copy-in/copy-out argument association rather than the
> simpler association by base address. Does that also apply to polymorphic
> class() arrays?

As noted above, it works for unknown size CHARACTER*(*),
where the system somehow passes the length along, and so
it could work for unknown sized CLASS, and should even
work for CLASS(*), again of unknown size.

[Themos Tsikas]

On Monday, 25 January 2021 at 07:46:16 UTC, Thomas Koenig wrote:
> Steve Lionel <st...@seesignature.invalid> schrieb:
> > "The code is (obviously?) technically valid, but I didn’t think it made
> > sense for non-assumed-shape dummies to be polymorphic, as they have to
> > be passed by dope vector not address anyway, and so I didn’t implement
> > it. No-one has ever complained!
> The way the message is worded, it makes the user think that the
> feature is actually not supported by the language, as opposed to
> the compiler. If people don't dig into the standard, they will be
> decieved into thinking that this is indeed illegal, expecially
> for a compiler like nagfor which has a reputation for being very
> standard-compliant.
>
> In that case, it might make sense to put an "Sorry, unimplemented"
> message in there and (possibly) issue an internal compiler error.
> It's what gfortran does.
>
> Personally, I'd think that would be much more user-friendly, but
> who am I to prescribe what other compiler writers do :-)

Hello,

this has now been done and the message will be
Polymorphic array X that is not deferred-shape or assumed-shape is not yet supported

I should also add that it is the custom for users to send an email to sup...@nag.co.uk or sup...@nag.com when they need assistance.

Themos Tsikas, NAG Ltd

[Thomas Koenig]

Themos Tsikas <themos...@gmail.com> schrieb:

> this has now been done and the message will be
> Polymorphic array X that is not deferred-shape or assumed-shape is not yet supported

Great!

> I should also add that it is the custom for users to send an email
> to sup...@nag.co.uk or sup...@nag.com when they need assistance.

I didn't want to bother you in case I had overlooked something in
the standard.

sup...@nag.co.uk will get any reports of any such problems (and
there already is another one where the question isn't that subtle :-)

[Themos Tsikas]

On Monday, 25 January 2021 at 12:31:34 UTC, Thomas Koenig wrote:
> I didn't want to bother you in case I had overlooked something in
> the standard.
>
> sup...@nag.co.uk will get any reports of any such problems (and
> there already is another one where the question isn't that subtle :-)

As you've found out, it all goes to Malcolm eventually! It's just faster to use the official route and is more economical with everybody's time. Consider me the equivalent of an Apollo CapCom.

Having a collaborative agreement in place with a sort-of-competitor can be tricky at times and I am determined to make it work because it raises everybody's game! Responses to your NAG compiler bug reports (from code in the gfortran test suite) will have to be prioritised while respecting existing commercial commitments. It's a business model that has worked well for us in the past and I am sure you will appreciate.

Best wishes,
Themos Tsikas, NAG Ltd.

[Steve Lionel]

On 1/25/2021 2:46 AM, Thomas Koenig wrote:
> In that case, it might make sense to put an "Sorry, unimplemented"
> message in there and (possibly) issue an internal compiler error.
> It's what gfortran does.

Malcolm now tells me he will change it to "not yet implemented".

[Thomas Koenig]

Themos Tsikas <themos...@gmail.com> schrieb:

> On Monday, 25 January 2021 at 12:31:34 UTC, Thomas Koenig wrote:
>> I didn't want to bother you in case I had overlooked something in
>> the standard.
>>
>> sup...@nag.co.uk will get any reports of any such problems (and
>> there already is another one where the question isn't that subtle :-)
>
> As you've found out, it all goes to Malcolm eventually! It's
> just faster to use the official route and is more economical with
> everybody's time. Consider me the equivalent of an Apollo CapCom.

:-)

> Having a collaborative agreement in place with a
> sort-of-competitor can be tricky at times and I am determined to
> make it work because it raises everybody's game!

Absolutely. I have (so far) closed one bug report against gfortran
as INVALID because nagfor clearly showed that there was an error
in the code, and what it was.

> Responses to your
> NAG compiler bug reports (from code in the gfortran test suite)
> will have to be prioritised while respecting existing commercial
> commitments. It's a business model that has worked well for us in
> the past and I am sure you will appreciate.

Sure. Bugs that I happen to stumble across while looking at
gfortran bugs are not high priority for anybody, but I think
that you (and Fortran in general) can still profit if you know
about them.

[Themos Tsikas]

We are in full agreement, thank you for your understanding.

Themos Tsikas, NAG Ltd.

[Ron Shepard]

It works by switching to copy-in/copy-out argument association, right?
That satisfies the standard, but the programmer should be aware of the
potentially enormous costs of (n) explicit shape declarations of dummy
arguments compared to (:) assumed shape declarations. I was not
disagreeing with the previous post, I was reinforcing the general point
it made that (n) and (:) have very different semantics and therefore
practical consequences.

$.02 -Ron Shepard