Aleksandar Donev said:
> So imagine a type like:
>
>   type allocatable_array
>      real, allocatable, dimension(:) :: array
>   end type allocatable_array
>
> and then:
>
>     type main_type
>         type(allocatable_array), pointer :: A, B, C
>     end type main_type
>
> The objects A, B and C are something in-between an array pointer and an
> allocatable array,

No, they are pointers.  Scalar pointers, but pointers nonetheless.

> and as far as problem 1 is concerned, guaranteed to
> be contiguous. But A can still be alliased with B or C, so one compiler
> I use will make temporaries for things like A%array=B%array+C%array even
> if they are not needed.

Well, you've gone out of your way to make aliasing a possibility, so it's
no surprise that a compiler does that.

Just don't do that!

The most obvious simple solution is to operate on them in a context
where they are not pointers; e.g. where they are (nonpointer) dummy
arguments.  (I mean that "A, B and C" are dummies, not that "A%array,
B%array and C%array" are dummies).

It is one of the inescapable facts of life that once you introduce
pointers into the equation, optimisation gets a lot more difficult and
it usually impossible to do as good a job as when pointers are not
present.

> Is the stand-point of most people in the committee that compilers should
> perform run-time checks for these kind of things? This can get tedious
> too, for the compiler and the produced executable...Or is the view that
> this is not really a problem (i.e. can be avoided by "better"
> programming) prevalent?

I don't think there is a committee consensus (there are two committees
for a start).  And why should that be of such interest?

If one has a problem with a vendor's product w.r.t. optimisation, my
view is that one should contact the vendor and point it out to them.
The vendor may be able to improve the accuracy of their alias analyser
or to suggest an alternative formulation of your program which avoids
the problem.  If you don't contact them they may remain unaware that
they have a problem in this area - and so the situation may never
improve!

Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
                           ([log in to unmask])

_____________________________________________________________________
This message has been checked for all known viruses by Star Internet
delivered through the MessageLabs Virus Scanning Service. For further
information visit http://www.star.net.uk/stats.asp or alternatively call
Star Internet for details on the Virus Scanning Service.