Fortran - Re: Which compiler is right?

Author

Re: Which compiler is right?

glen herrmannsfeldt

2004-03-27, 12:16 am

Richard Maine wrote:
> hchu@thermawave.com (Hanyou Chu) writes:

> (Ah. This might be the specifics I was asking for in reply
> to a post just a minute ago).

[color=darkred]
> *******I assume this is a transcription error
> and that you meant a(n)

[color=darkred]
[color=darkred]
> Yes, this looks valid (if the presumed transcription error is fixed).

> Although this is valid, are you really sure it is what they
> want to do? Do they realize this will almost certainly cause
> copy-in/copy-out of the argument?

> The standard does specify that c%a is an array of 10 real(8)
> elements. It happens to be a discontiguous array slice
> (much like a row of a rank2 array), but that's fine.

> So its performance might be poor, but it should work.
> You might get better performance by doing

Performance is a complicated problem in cases like this.
There is another thread discussing the effects of a cache on
problems like this. While there is a cost to the copy in/copy out
the actual access of the data after copying might be faster.
If there are many loops over the array, and probably if it
is larger than 8 elements, it may fit better in the cache,
and more than make up for the copying cost.

If it is only accessed once, you can be pretty sure that the
copy will be slower.

-- glen

Hanyou Chu

2004-03-27, 12:17 am

>
> (Ah. This might be the specifics I was asking for in reply
> to a post just a minute ago).
>
> *******I assume this is a transcription error
> and that you meant a(n)
>
> Yes, this looks valid (if the presumed transcription error is fixed).

It was a transcription error.

The error message was so cryptic, it took me quite a while to figure
out what it complained about. If it is valid, I should send a report
to Absoft. On the other hand this should definitely be avoided
if possible. A warning should be fine.

> Although this is valid, are you really sure it is what they
> want to do? Do they realize this will almost certainly cause
> copy-in/copy-out of the argument?

I am sure it is what they wanted to do, but I don't think they did
realize it can cause copy-in/copy-out of the argument.

>
> The standard does specify that c%a is an array of 10 real(8)
> elements. It happens to be a discontiguous array slice

This is probably what Absoft assumed and why it refused to compile.

> (much like a row of a rank2 array), but that's fine.
>
> So its performance might be poor, but it should work.

If temporary arrays are used for copy-in/copy-out of course.

> You might get better performance by doing
>
> call sub(c%a)
>
> and
>
> subroutine sub(a)
> real(8) a(:)
>
> though in that case, the interface of sub needs to be
> explicit.

I am not sure about this though.

Hanyou Chu

2004-03-27, 12:17 am

It should be:

subroutine sub(a,n)
real(8),intent(out):: a(n)
...
end

subroutine caller(a,c)
type atype
real(8) a,b
end type
type(atype),intent(out):: c(10)
call sub(c%a,10)
...
end

Actually I did a few tests and realize that it is the
qualifier "intent(out)" as in
type(atype),intent(out):: c(10)
that caused the problem, because c%y is not set. It is just that
the error messages always point to the line that contains the
call, which made me think that it is related to the seemingly
inconsistent call.

Then, should it be treated as an error when c%b is not set?

Richard Maine

2004-03-27, 12:17 am

I said:

hchu@thermawave.com (Hanyou Chu) writes:
[color=darkred]
> I am sure it is what they wanted to do, but I don't think they did
> realize it can cause copy-in/copy-out of the argument.

If they didn't realize that, then I don't know how they knew this is
what they wanted to do. Assumed shape dummy arguments aren't a
universal solution to all woes; as some here will tell you, the
performance issues are complicated. But if the authors of this code
didn't know about the likely copy, and the possible alternative of
assumed shape, then I'd say they didn't have enough information to
make an informed choice.

>
> This is probably what Absoft assumed and why it refused to compile.

That should not cause a compilation failure. The standard requires
it to work. But...

From your other post, I gather that the actual problem had nothing
to do with this, but instead was from an inappropriate intent.

Sigh. I should learn. At times I'm a real nag about making
people show me the actual error messages instead of telling me what
they think caused the message. Even if the message is cryptic to you,
it might be understandable to me (or maybe not, but I have to see it
to tell). It figures that when I skip that nag and assume that I'm
looking at the right thing, that would be one of the times when I
really should have insisted on seeing the actual error message. :-(

--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

Jan C. Vorbrüggen

2004-03-27, 12:17 am

> Then, should it be treated as an error when c%b is not set?

No, it shouldn't be an error, only a warning - technically, c%b is
undefined after the call, and it's the programmer's responsibility
to make sure these undefined values aren't used, not the compiler's
or the program's.

Jan

Richard Maine

2004-03-27, 12:17 am

Xref: kermit comp.lang.fortran:80918

Jan C. Vorbrüggen <jvorbrueggen@mediasec.de> writes:

>
> No, it shouldn't be an error...

That was my initial inclination, but... having just been "burned"
in this same thread, I don't think I'll make a judgement at all
unless I see an actual compilable code sample (without ellipses)
and a corresponding actual error message. All I see is still
an abstract of code, which might well omit the parts that actually
trigger the error, along with the OP's explanation of what he
thinks the error message is about. That's not adequate for me
to judge from here.

--
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

Sponsored Links