Print

---

Feyzi Inanc writes:

 > The very same code crashes on this cluster.  It does not like some
 > (not all) "allocate" statements.

"Does not like" is a bit on the vague side, as is "some (not all)".
Specifics would be a lot more helpful.  "Does not like" sounds to me
as though you are saying that they fail to compile, but your
references to "crashes" sound more like a run-time error.

It would be helpful to know exactly what error messages you are
seeing in what context.

Without more data, about the only speculations I can offer are the
following possible ways that I can easily imagine "some (not all)"
allocate statements crashing.

1. Of course, if you don't have enough memory for the requested
   allocation, something is going to fail.  Exactly how will depend
   on both the compiler and your code (whether or not you use stat=
   in the allocate).

   And this includes cases like your system having enough memory, but
   something not configured to allow you to use all of it.

   This is certainly a way that some, but not all, allocations might fail.

2. If you try to allocate an allocatable that is currently allocated,
   it might fail.  That is illegal (you are supposed to deallocate any
   previous allocation first), but some compilers might just ignore it
   and do the deallocation as an extension.  (I'm not sure how
   "friendly" an extension that would be, as it might well be hiding a
   bigger error, but its the kind of thing some compilers might do).

   If you have particular allocations that are failing, you might
   use the ALLOCATED intrinsic to check for this problem right before
   the allocate statements in question.

3. I'm sure there are plenty of other ways, including things like
   random code bugs that overwrite allocation information by exceeding
   array bounds or something of the sort.  But this is a bit vague to
   be very helpful.  I suppose it might suggest one of the "usual"
   generic things - try turning on all the diagnostic options that the
   compiler provides, both compile-time and run-time checks.

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%