Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Fortran Programming Language

Reassociation of pointers


Dear group,

in our simulation package, we employ a self-written storage module. In
short, each array 1D/2D is given an integer handle which is much easier
to pass through all routines. The storage module keeps a list of handles
and its associated memory blocks. I am trying to implement some
conversion routine between 1D and 2D arrays. In principle it works,
e.g., with G95 it it crashes with Intel Fortran 9.1 (20061103).

Here is a small demo program which illustrates the idea. Note that in
our storage module, the pointer p1 and p2 are "hidden" in the module so
that the application programmer will not see/manipulate them. He can
only create a new 1D array, then p1 is used or a 2D array, then p2 is used.

 >>>>

program mem
   implicit none

   ! 1D and 2D pointers
   real, dimension(:),   pointer :: p1
   real, dimension(:,:), pointer :: p2

   ! Allocate memory for a 2D pointer of size 3x10
   allocate(p2(3,10))

   p2(1,:)=1
   p2(2,:)=2
   p2(3,:)=3

   ! Convert the 2D pointer to a 1D pointer
   ! Note, first dimension comes first!
   call convert2d(size(p2),p2,p1)
   nullify(p2)

   ! Check if p1 is correct
   print *, p1

   ! Here, many things can be done with the 1D array, e.g.,
   ! update the data...

   ! At the and of the simulation, deallocate memory.
   ! p2 is not associated any longer. Hence, deallocate p1
   deallocate(p1)

contains

   subroutine convert2d(n,mem2d,mem1d)
     integer, intent(in) :: n
     real, dimension(n), target  :: mem2d
     real, dimension(:), pointer :: mem1d

     mem1d => mem2d
   end subroutine convert2d

end program mem
<<<<<

The deallocate statement works with g95 but crashes ifort:

forrtl: severe (173): A pointer passed to DEALLOCATE points to an array
that cannot be deallocated
Image              PC        Routine            Line        Source
mem                080810BC  Unknown               Unknown  Unknown
mem                08080081  Unknown               Unknown  Unknown
mem                0807B2CB  Unknown               Unknown  Unknown
mem                08058658  Unknown               Unknown  Unknown
mem                0804EE8D  Unknown               Unknown  Unknown
mem                08049A83  MAIN__                     28  mem.f90
mem                08049506  Unknown               Unknown  Unknown
libc.so.6          B7E75F9C  Unknown               Unknown  Unknown

Perhaps you can help me in converting 1D pointers to 2D pointers and
vice versa.

Many thanks in advance,
Matthias Moeller

Matthias Mller wrote:

| Dear group,
|
| in our simulation package, we employ a self-written storage module. In
| short, each array 1D/2D is given an integer handle which is much easier
| to pass through all routines. The storage module keeps a list of handles
| and its associated memory blocks. I am trying to implement some
| conversion routine between 1D and 2D arrays. In principle it works,
| e.g., with G95 it it crashes with Intel Fortran 9.1 (20061103).
|
| Here is a small demo program which illustrates the idea. Note that in
| our storage module, the pointer p1 and p2 are "hidden" in the module so
| that the application programmer will not see/manipulate them. He can
| only create a new 1D array, then p1 is used or a 2D array, then p2 is used.

Um, the demo is hardly compilable as-is with all that rank mismatches
in convert2d. Can you post a working example?

In any case, I suspect that your run-time error comes from a situation
like:

integer, allocatable, target:: T(:)
integer, pointer::             P(:)

allocate(T(10))
P => T
deallocate(P)

Um... this doesn't crash in ifort for Windows 9.1.037. Steve ?!

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Matthias Mller <moeller.matth@gmx.de> wrote:
>    real, dimension(:),   pointer :: p1
>    real, dimension(:,:), pointer :: p2

>    ! Allocate memory for a 2D pointer of size 3x10
>    allocate(p2(3,10))

...[make p1 point to the same memory as p2]

>    deallocate(p1)
...
> The deallocate statement works with g95 but crashes ifort:
...
> Perhaps you can help me in converting 1D pointers to 2D pointers and
> vice versa.

While I didn't check all the fine details, it looks like you suceeded in
converting the 1D pointers to 2D ones. I think that trick has been
discussed here before. Hmm. I'm wondering whether the trick is valid in
that direction - I have my doubts, as some 2D pointers can point to
memory layouts that can't be pointed to by 1D pointers, and the standard
doesn't have a way to distinguish which ones can or can't. (I can
distinguish, but the standard can't - at least not f95). I think you are
safer going the other way, at least in terms of standard conformance. I
don't have citations for that handy; its a tricky area. But I'll pass
over that for now and assume it is ok.

However, just because you managed to make the 1D pointer point to the
same memory as 2D one, that doesn't mean it is valid to deallocate the
1D one. There are some conditions about what you can deallocate. The
conditions include some "obvious" stuff (you can't deallocate a target
that asn't allocated - for example, a static target), but it also has
some fine points, at least one of which was even once the subject of an
interp. Researching those fine points would take me some time, but my
intuition suggests that your code is unlikely to meet the conditions and
that any other method of getting a 1D pointer to memory allocated as 2D
will have the same problem.

You can get such a pointer, but I don't think you can validly deallocate
it. Of course, it might happen to work anyway with some compilers.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

> Um, the demo is hardly compilable as-is with all that rank mismatches
> in convert2d. Can you post a working example?

Hm, it IS compilable on my machines (linux) both with g95 and ifort.

> In any case, I suspect that your run-time error comes from a situation
> like:

> integer, allocatable, target:: T(:)
> integer, pointer::             P(:)

> allocate(T(10))
> P => T
> deallocate(P)

> Um... this doesn't crash in ifort for Windows 9.1.037. Steve ?!

No, this does not crash on my machine, either. The point is, I want to
convert s pointer T(:,:) to a pointer P(:) and vice versa without
copying data from one pointer to another. To my mind, T(:,:) is stored
as one large array in memory, and hence, it should be possible to use it
as such without copying memory blocks, isn't it?

Many thanks in advance,

Matthias

Jugoslav Dujic <jdu@yahoo.com> wrote:
> Um, the demo is hardly compilable as-is with all that rank mismatches
> in convert2d. Can you post a working example?

Have you tried compiling it? I didn't (short on time), but I see no such
rank mismatch in convert2d. Have you forgotten about sequence
association for arguments, which is a critical part of this?

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Richard Maine wrote:

| Jugoslav Dujic <jdu@yahoo.com> wrote:
|
|| Um, the demo is hardly compilable as-is with all that rank mismatches
|| in convert2d. Can you post a working example?
|
| Have you tried compiling it? I didn't (short on time), but I see no such
| rank mismatch in convert2d. Have you forgotten about sequence
| association for arguments, which is a critical part of this?

I haven't forgot about the sequence association, but merely misread the
code :-). I relied on my /highly reliable/ Human Code Parser (TM) rather
than the old-fashioned compiler...

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Richard Maine wrote:

| Matthias Mller <moeller.matth@gmx.de> wrote:
|
||    real, dimension(:),   pointer :: p1
||    real, dimension(:,:), pointer :: p2
||
||    ! Allocate memory for a 2D pointer of size 3x10
||    allocate(p2(3,10))
| ...[make p1 point to the same memory as p2]
||    deallocate(p1)
| ...
|| The deallocate statement works with g95 but crashes ifort:
| ...
|| Perhaps you can help me in converting 1D pointers to 2D pointers and
|| vice versa.
|
<snip>
| However, just because you managed to make the 1D pointer point to the
| same memory as 2D one, that doesn't mean it is valid to deallocate the
| 1D one. There are some conditions about what you can deallocate. The
| conditions include some "obvious" stuff (you can't deallocate a target
| that asn't allocated - for example, a static target), but it also has
| some fine points, at least one of which was even once the subject of an
| interp. Researching those fine points would take me some time, but my
| intuition suggests that your code is unlikely to meet the conditions and
| that any other method of getting a 1D pointer to memory allocated as 2D
| will have the same problem.
|
| You can get such a pointer, but I don't think you can validly deallocate
| it. Of course, it might happen to work anyway with some compilers.

Yep, I tested it, and you're spot on (as alw^H^H^H usual :-) ).

Matthias, take a look at documentation of (new?) FOR_DESCRIPTOR_ASSIGN
VF routine, as it sort of explains the behavior and implementation of
VF pointers and allocatables. I checked through the debugger and found
out that your statement:

mem1d => mem2d

sets the FOR_DESCRIPTOR_ARRAY_NODEALLOC bit in mem1d (p1) descriptor,
as expected -- all the compiler "knows" (because you "cheated") is that
you're pointing mem1d to a sequence-associated target, for which it
cannot proof that it "owns" the allocated memory (i.e. you must not
deallocate a pointer which points to something which isn't previously
ALLOCATEd through a pointer). Like Richard said, it might happen to
work anyway with some compilers.

Well, you can "cheat" further and clear up the said bit, through it's
doomed to be unportable. I cannot foresee a "portable" "cheat" of this
kind -- anyone?

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Jugoslav Dujic <jdu@yahoo.com> wrote:
> Richard Maine wrote:
> | Jugoslav Dujic <jdu@yahoo.com> wrote:
> |
> || Um, the demo is hardly compilable as-is with all that rank mismatches
> || in convert2d. Can you post a working example?
> |
> | Have you tried compiling it? I didn't (short on time), but I see no such
> | rank mismatch in convert2d. Have you forgotten about sequence
> | association for arguments, which is a critical part of this?

> I haven't forgot about the sequence association, but merely misread the
> code :-). I relied on my /highly reliable/ Human Code Parser (TM) rather
> than the old-fashioned compiler...

Been there; done that. :-(

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Richard Maine wrote:

(snip)

> You can get such a pointer, but I don't think you can validly deallocate
> it. Of course, it might happen to work anyway with some compilers.

I presume you also aren't supposed to deallocate the pointers
from C_F_POINTER, though I don't see where it says that.

-- glen

glen herrmannsfeldt wrote:
> Richard Maine wrote:

> (snip)

>> You can get such a pointer, but I don't think you can validly deallocate
>> it. Of course, it might happen to work anyway with some compilers.

> I presume you also aren't supposed to deallocate the pointers
> from C_F_POINTER, though I don't see where it says that.

> -- glen

It says it indirectly in the deallocate statement discussion.

"6.3.3.2 Deallocation of pointer targets
... Deallocating a pointer that is disassociated or whose target
was not created by an ALLOCATE statement causes an error condition in
the DEALLOCATE statement."

Dick Hendrickson

On Apr 26, 2:29 pm, glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:

> I presume you also aren't supposed to deallocate the pointers
> from C_F_POINTER, though I don't see where it says that.

The standard says: "Deallocating a pointer that is disassociated or
whose target
was not created by an ALLOCATE statement causes an error condition in
the
DEALLOCATE statement."  Since the pointer created by C_F_POINTER was
not
created by ALLOCATE, then it would not be allowed to DEALLOCATE it.

I know what's happening in the OP's case - in our implementation
there's a bit
in the pointer "descriptor" which says "Disallow DEALLOCATE".  This
gets
cleared for the result of an ALLOCATE and when you do a pointer
assignment from
another pointer that has the bit cleared.  The bit gets set if you do
a pointer
assignment to a slice of a pointer array or, as in this case, to
something that
isn't a pointer.

The OP's program is a bit weird - the target of the pointer assignment
is not
itself a pointer but it is associated with the storage from a pointer
that was
ALLOCATEd.  Our method doesn't consider this legal for a DEALLOCATE.
I'd have
to go read the interpretations to see what else has been written about
it - I'm
not willing to consider it a bug at this time. A different
implementation would
be to allocate some extra memory for an address and length and compare
that
when doing the deallocate (making sure that the storage to be
deallocated was
contiguous.)

I'm not comfortable with programs that try to "trick" the compiler
into doing
things the language doesn't ordinarily allow.  I'd suggest that this
sort of
thing might be done in a more straightforward way with C_LOC and
C_F_POINTER,
as long as you didn't try to DEALLOCATE the newly molded pointer.  No,
you
can't do this in Intel Fortran 9.1, but soon...

Steve

Steve Lionel <steve.lio@intel.com> wrote:
> I'd suggest that this sort of
> thing might be done in a more straightforward way with C_LOC and
> C_F_POINTER,

I thought of mentioning something simillar. The C_PTR stuff in the f2003
C interop is good for many things, some of which don't actually have
much to do with C. This is one example.

> as long as you didn't try to DEALLOCATE the newly molded pointer.

Yes, I'd expect the same kind of issue with that for simillar reasons.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Steve Lionel wrote:

| On Apr 26, 2:29 pm, glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:
|
|| I presume you also aren't supposed to deallocate the pointers
|| from C_F_POINTER, though I don't see where it says that.
|
| The standard says: "Deallocating a pointer that is disassociated or
| whose target
| was not created by an ALLOCATE statement causes an error condition in
| the
| DEALLOCATE statement."  Since the pointer created by C_F_POINTER was
| not
| created by ALLOCATE, then it would not be allowed to DEALLOCATE it.

But could you please take a look as well at my initial counter-example:

integer, allocatable, target:: T(:)
integer, pointer:: P(:)

allocate(T(10))
P => T
deallocate(P)
print *, allocated(T)  !Prints "T"
T(1) = 42

I'd (naively?) expect this code to fail at deallocate(P) with the
same error message as the OP's. However, instead, in the latest IVF,
it just nullifies P and (apparently, I cannot be sure) leaves
T allocated as it was. My understanding is that you cannot
deallocate an ALLOCATABLE through an associated POINTER. Am I
right? If I am, I think it's a bug in IVF*

*) or just a quality of implementation issue?

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

On Apr 27, 9:01 am, "Jugoslav Dujic" <jdu@yahoo.com> wrote:

No, you're wrong. Deallocating P in your code is OK, because it's
target _was_ created by ALLOCATE and is not ALLOCATABLE
(6.3.3.2:20-23). After the deallocation, however, the association
status of T is undefined (6.3.3.2:24-26), so you virtually should do
nothing with it until you ALLOCATE or NULLIFY it.
highegg wrote:

| On Apr 27, 9:01 am, "Jugoslav Dujic" <jdu@yahoo.com> wrote:
|| Steve Lionel wrote:

||
||| On Apr 26, 2:29 pm, glen herrmannsfeldt <g@ugcs.caltech.edu> wrote:
|||
|||| I presume you also aren't supposed to deallocate the pointers
|||| from C_F_POINTER, though I don't see where it says that.
|||
||| The standard says: "Deallocating a pointer that is disassociated or
||| whose target
||| was not created by an ALLOCATE statement causes an error condition in
||| the
||| DEALLOCATE statement."  Since the pointer created by C_F_POINTER was
||| not
||| created by ALLOCATE, then it would not be allowed to DEALLOCATE it.
||
|| But could you please take a look as well at my initial counter-example:
||
|| integer, allocatable, target:: T(:)
|| integer, pointer:: P(:)
||
|| allocate(T(10))
|| P => T
|| deallocate(P)
|| print *, allocated(T)  !Prints "T"
|| T(1) = 42
||
|| I'd (naively?) expect this code to fail at deallocate(P) with the
|| same error message as the OP's. However, instead, in the latest IVF,
|| it just nullifies P and (apparently, I cannot be sure) leaves
|| T allocated as it was. My understanding is that you cannot
|| deallocate an ALLOCATABLE through an associated POINTER. Am I
|| right? If I am, I think it's a bug in IVF*
||
|| *) or just a quality of implementation issue?
||
| No, you're wrong. Deallocating P in your code is OK, because it's
| target _was_ created by ALLOCATE and is not ALLOCATABLE
| (6.3.3.2:20-23). After the deallocation, however, the association
| status of T is undefined (6.3.3.2:24-26), so you virtually should do
| nothing with it until you ALLOCATE or NULLIFY it.

Um, my target IS an allocatable. Did the persons named J**oslav
start suffering from folie a deux ;-) ?

OK, found it (though I don't have a fresh copy of the standard):

20 If a pointer appears in a DEALLOCATE statement, its association
   status shall be defined. Deallocating
21 a pointer that is disassociated or whose target was not created
   by an ALLOCATE statement causes an
22 error condition in the DEALLOCATE statement. If a pointer is
   associated with an allocatable entity,
23 the pointer shall not be deallocated.

but I do have a problem with the last sentence -- namely, it
(apparently though not straight enough) does say that the
[target] shall not be deallocated, but does not say what would
be the status of the pointer afterwards. IVF apparently choose
to nullify, but doing nothing (i.e. P remains associated with T)
appears to satisfy the wording quite as well. Or... ?

24-26 don't seem relevant to me -- they refer to the "dangling"
pointer phenomena.

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

On Apr 27, 10:52 am, "Jugoslav Dujic" <jdu@yahoo.com> wrote:

Huh, sorry, I must have been temporarily blinded. I suppose it's the
solar erections kind of thing.

after what? You mean after you deallocate it? When the standard says
that something "shall not" be done and you do it anyway your code is
out of standard. The standard does not specify what a non-standard
code should or should not do.
IMO, at least.

regards,
Jaroslav

highegg wrote:

| On Apr 27, 10:52 am, "Jugoslav Dujic" <jdu@yahoo.com> wrote:
|| highegg wrote:

[snip a ton]
||| No, you're wrong. Deallocating P in your code is OK, because it's
||| target _was_ created by ALLOCATE and is not ALLOCATABLE
||| (6.3.3.2:20-23). After the deallocation, however, the association
||| status of T is undefined (6.3.3.2:24-26), so you virtually should do
||| nothing with it until you ALLOCATE or NULLIFY it.
||
|| Um, my target IS an allocatable. Did the persons named J**oslav
|| start suffering from folie a deux ;-) ?
|
| Huh, sorry, I must have been temporarily blinded. I suppose it's the
| solar erections kind of thing.
|
||
|| OK, found it (though I don't have a fresh copy of the standard):
||
|| 20 If a pointer appears in a DEALLOCATE statement, its association
||    status shall be defined. Deallocating
|| 21 a pointer that is disassociated or whose target was not created
||    by an ALLOCATE statement causes an
|| 22 error condition in the DEALLOCATE statement. If a pointer is
||    associated with an allocatable entity,
|| 23 the pointer shall not be deallocated.
||
|| but I do have a problem with the last sentence -- namely, it
|| (apparently though not straight enough) does say that the
|| [target] shall not be deallocated, but does not say what would
|| be the status of the pointer afterwards. IVF apparently choose
|| to nullify, but doing nothing (i.e. P remains associated with T)
|| appears to satisfy the wording quite as well. Or... ?
|
| after what? You mean after you deallocate it? When the standard says
| that something "shall not" be done and you do it anyway your code is
| out of standard. The standard does not specify what a non-standard
| code should or should not do.
| IMO, at least.

OK, my turn to get hit by the solar flares; "the pointer shall not
be deallocated" actually means "you may not deallocate such pointer".
I didn't switch my brains into Standardese language mode.

Which gets us back where we started from (i.e. my complaint on IVF):
while the standard doesn't specify what should be done, it would be
nice that the code dies with:

forrtl: severe (173): A pointer passed to DEALLOCATE points to an array
that cannot be deallocated

IOW, in Intel implementation, the statement

P => T

whenever T is not a pointer, should set the flag
FOR_DESCRIPTOR_ARRAY_NODEALLOC in P's descriptor. As I verified, it
does not in this case. Steve? Need I post this to Premier support?

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

On Apr 27, 12:23 pm, "Jugoslav Dujic" <jdu@yahoo.com> wrote:

I'd call that an "enhancement suggestion" rather than a complaint.
"would be nice" is the right wording. I think you can't really expect
a compiler to identify and report (compile or run time) every non-
standard code.

>IOW, in Intel implementation, the statement

>P => T

>whenever T is not a pointer, should set the flag
>FOR_DESCRIPTOR_ARRAY_NODEALLOC in P's descriptor. As I verified, it
>does not in this case. Steve? Need I post this to Premier support?

Admittedly, it's sort of weird that the standard permits deallocation
of static arrays
(which should end up with error condition), but simply forbids
deallocating of allocatables.
highegg wrote:

| On Apr 27, 12:23 pm, "Jugoslav Dujic" <jdu@yahoo.com> wrote:
|| highegg wrote:

||
||| On Apr 27, 10:52 am, "Jugoslav Dujic" <jdu@yahoo.com> wrote:|| highegg
||| wrote:

||
 [snip still more]
|||| OK, found it (though I don't have a fresh copy of the standard):
||||
|||| 20 If a pointer appears in a DEALLOCATE statement, its association
||||    status shall be defined. Deallocating
|||| 21 a pointer that is disassociated or whose target was not created
||||    by an ALLOCATE statement causes an
|||| 22 error condition in the DEALLOCATE statement. If a pointer is
||||    associated with an allocatable entity,
|||| 23 the pointer shall not be deallocated.
||||
|||| but I do have a problem with the last sentence -- namely, it
|||| (apparently though not straight enough) does say that the
|||| [target] shall not be deallocated, but does not say what would
|||| be the status of the pointer afterwards. IVF apparently choose
|||| to nullify, but doing nothing (i.e. P remains associated with T)
|||| appears to satisfy the wording quite as well. Or... ?
|||
||| after what? You mean after you deallocate it? When the standard says
||| that something "shall not" be done and you do it anyway your code is
||| out of standard. The standard does not specify what a non-standard
||| code should or should not do.
||| IMO, at least.
||
|| OK, my turn to get hit by the solar flares; "the pointer shall not
|| be deallocated" actually means "you may not deallocate such pointer".
|| I didn't switch my brains into Standardese language mode.
||
|| Which gets us back where we started from (i.e. my complaint on IVF):
|| while the standard doesn't specify what should be done, it would be
|| nice that the code dies with:
||
|| forrtl: severe (173): A pointer passed to DEALLOCATE points to an array
|| that cannot be deallocated
|
| I'd call that an "enhancement suggestion" rather than a complaint.
| "would be nice" is the right wording. I think you can't really expect
| a compiler to identify and report (compile or run time) every non-
| standard code.

Yep, on very careful reading of the Standard, it appears that ifort
is not wrong in the strict sense...

|| IOW, in Intel implementation, the statement
||
|| P => T
||
|| whenever T is not a pointer, should set the flag
|| FOR_DESCRIPTOR_ARRAY_NODEALLOC in P's descriptor. As I verified, it
|| does not in this case. Steve? Need I post this to Premier support?
|
| Admittedly, it's sort of weird that the standard permits deallocation
| of static arrays
| (which should end up with error condition), but simply forbids
| deallocating of allocatables.

...but here, I'd (wildly) speculate that such wording was a
concession to some compiler-makers whose design couldn't permit such
a run-time check, so they turned the burden to the user. Since
ifort's design (appears to be) is capable of such check, I guess
it would be appropriate to ask them to implement it.

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

On Apr 27, 8:13 am, "Jugoslav Dujic" <jdu@yahoo.com> wrote:

> ...but here, I'd (wildly) speculate that such wording was a
> concession to some compiler-makers whose design couldn't permit such
> a run-time check, so they turned the burden to the user. Since
> ifort's design (appears to be) is capable of such check, I guess
> it would be appropriate to ask them to implement it.

This is an interesting wrinkle which I don't think we considered
before.  I'll pass on the suggestion. Thanks.

As most of us are aware by now, the Fortran standard describes the
behavior of a standard-conforming program and includes many "thou
shalt not" statements.  "Processors'" (compilers, etc.) are required
to diagnose some misbehaviors (violations of constraints) but not all
of the prohibitions.

Steve

| Admittedly, it's sort of weird that the standard permits deallocation
| of static arrays
     ^^^^^
-------|

...and, watch your tongue, Jaroslav; Richard is almost certainly
listening :-))

--
 Jugoslav
___________
www.xeffort.com

Please reply to the newsgroup.
You can find my real e-mail on my home page above.

Jugoslav Dujic <jdu@yahoo.com> wrote:
> | Admittedly, it's sort of weird that the standard permits deallocation
> | of static arrays
>      ^^^^^
> -------|

> ...and, watch your tongue, Jaroslav; Richard is almost certainly
> listening :-))

Eh? :-)

Actually, I agree with highegg (who appears to have written the words in
question) on this. I also think I recall a vendor mentioning that he had
to go to significant extra work to make sure that this always worked as
specified in the standard. Details of the cases the vendor had trouble
with long forgotten, as that was som etime ago.

--
Richard Maine                    | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle           |  -- Mark Twain

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc