Un-use-ual subroutine name causes ICE
I was trying to put an example together for a different problem and frankly got rather lost. So the attached makes
very little sense, but it does cause a "fortcom: Fatal: .... (C00000005)" with 11.1.051.
Thanks,
IanH
| |
Re: Un-use-ual subroutine name causes ICE
Another example attached (TryingToBeGeneric.f90) that gives an ICE with 11.1.051, which is probably unrelated to the
previous one (message is "internal error: Please visit...").
While I've still got your attention... some
F2003 polymorphism questions. This example (TryingToBeSpecificInAnAbstractWay.f90), when compiled with /check:all /warn:all
/traceback, compiles, but then dies with an access violation, apparently at the ALLOCATE statement (the very first
executable statement of the program proper!). This is a bit disappointing even for me - normally I make it at least
ten lines in before everything's gone to pot - so any hints appreciated. Without /check:all /warn:all the crash pops
up later.
Second question is around type compatibility of polymorphic dummy and actual arguments. The
previous example has an abstract "base" type (AbstractType) and then a "concrete" extension of that type
(AbstractTypeExt). There is then a procedure (not a type bound one) that has a "CLASS(AbstractType), INTENT(IN) ::
obj" dummy. Quoting from the good PDF... "A polymorphic entity that is not an unlimited polymorphic entity is type
compatible with entities of the same type or any of its extensions". As a result, I would have thought that I could
poke in a TYPE(AbstractTypeExt) actual argument to that procedure (see commented out statements with !xxx). Under
11.1.51 that doesn't "match" and I have to use the obj%parent syntax to get things to work. Is that just a IVF F2003
implementation-not-there-yet-issue, or an IanH F2003 standard-still-beyond-your-comprehension issue?
Thanks,
IanH
| |
Re: Un-use-ual subroutine name causes ICE
Thanks for the assistance.
Another F2003/11.1.051 question - does a user defined type with an
allocatable component have the component de-allocated on entry to a procedure when its associated with a dummy arg
that's declared CLASS(xxx), INTENT(OUT)? I know it does for TYPE(xxx), INTENT(OUT), but the behaviour when the dummy
is declared with class seems to be different. With the attached I get told off at runtime for trying to allocate
something that's already allocated.
I've finished my conversion-from-C++ learning exercise, back to
lurking.
Ta,
IanH
| |
Re: Un-use-ual subroutine name causes ICE
Ian,
Yes, the deallocation of components of a polymorphic type should be done for INTENT(OUT)
arguments. A similar issue arises for local polymorphic variables with allocatable components on routine exit. Our
compiler completely misses these cases. The developers knew about the second but had not yet considered the first -
that is our issue DPD200141685.
Unfortunately, we have to invent some new mechanisms in the compiler to deal
with this and I don't expect it to be fixed soon. A workaround is to do a SELECT TYPE, test for allocation and
deallocate manually, but you shouldn't have to do that.
Steve
Attaching or including files in a post
Doctor Fortran blog
@DoctorFortran on Twitter | |
Re: Un-use-ual subroutine name causes ICE
We have decided that TryingToBeSpecificInAnAbstractWay is not legal Fortran. In the future, the compiler will
give:
error #8307: If the rightmost part-name is of abstract type, data-ref shall be polymorphic
[ABSTRACTTYPE]
We had quite a lively argument about this and even went so far as to consult other standards
committee members to see what they thought of it. We note that the NAG compiler also gives an access violation for this
same program.
Steve
Attaching or including files in a post
Doctor Fortran blog
@DoctorFortran on Twitter | |
Re: Un-use-ual subroutine name causes ICE
We have decided that TryingToBeSpecificInAnAbstractWay is not legal
Fortran. In the future, the compiler will give:
error #8307: If the rightmost part-name is of abstract
type, data-ref shall be polymorphic [ABSTRACTTYPE]
We had quite a lively argument about this and even went
so far as to consult other standards committee members to see what they thought of it. We note that the NAG compiler
also gives an access violation for this same program.
Thanks for the response.
I see in the standard where that restriction comes from, but I can't see where
that restriction is being violated in the code. Could you (or someone else with F2003 experience) please elaborate?
Possibly unrelated to your point, but you don't need abstract types to cause an access violation in ALLOCATE
- see snippet below (with 11.1.54, seems to need /warn:all at the command line to see the problem, which is odd in
itself in that a compile time diagnostic option triggers a run time error):
MODULE ClassAllocateMod
IMPLICIT NONE
PRIVATE
! Concrete class with single bound proc
TYPE, PUBLIC :: Base
INTEGER base_comp
CONTAINS
PROCEDURE :: proc => base_proc
END TYPE Base
CONTAINS
SUBROUTINE base_proc(this)
CLASS(Base), INTENT(IN) :: this
!****
WRITE (*, "(A)") 'Hello!'
END SUBROUTINE base_proc
END MODULE ClassAllocateMod
PROGRAM ClassAllocate
USE ClassAllocateMod
IMPLICIT NONE
CLASS(Base), ALLOCATABLE :: obj
!****
ALLOCATE(obj) ! boom
CALL obj%proc
END PROGRAM ClassAllocate
I wondered whether it was having the ALLOCATE as an executable statement in at PROGRAM level that was the problem,
bit when I added the following lines of code to the same source file I get a "catastrophic error" (again, needs
/warn:all to see the problem).
MODULE ICE_machine
USE ClassAllocateMod
IMPLICIT NONE
CONTAINS
SUBROUTINE Util
CLASS(Base), ALLOCATABLE :: obj
!****
ALLOCATE(obj)
CALL obj%proc
END SUBROUTINE Util
END MODULE ICE_machine
Thanks for any pointers. Note that I'm not at all familar with F2003 OOP, so apologies if these learning exercises
throws out a few red herrings which are programmer errors rather than compiler issues.
IanH
| |
Re: Un-use-ual subroutine name causes ICE
It's /warn:interface that is causing the problem for these last two. It's not supposed to change the generated
code, but sometimes, due to a bug, it does. Both of them are ok in our latest internal sources, but I can reproduce
the error in the released compiler.
The issue with TryingToBeSpecificInAnAbstractWay comes down to the
interpretation of b%AbstractType as an actual argument. AbstractType is the parent type of AbstractTypeExt where b is
CLASS(AbstractTypeExt). The question is: "what is the 'data-ref' here"? Is it b or is it b%AbstractType? Initially,
I claimed it was b, which is polymorphic, but others said it was the whole thing, b%AbstractType, which if you look at
it in the larger context of the actual argument is true.
To be honest, I still find myself confused about
this, but enough "experts" agreed that it was an error that I'll go along with it. This polymorphic stuff still gives
me a headache (and still gives the compiler indigestion at times.)
Steve
Attaching or including files in a post
Doctor Fortran blog
@DoctorFortran on Twitter | | |
