Intel® Software Network

Thanks - we'll take a look.

Very amusing...  Escalated as issue DPD200141584.  Both the calls to SET and USE are required to trigger the error, at least in this example.  As you discovered, renaming USE to something else avoids the error.

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

Ian,

Thanks for these additional items. It will take me a few days to sort out the issues and get back to you.  The issue you describe about type matching sounds familiar and may be a bug already reported but not yet fixed. I'll check into it.

TryingToBeGeneric is issue DPD200141626.  TryingToBeSpecificInAnAbstractWay is issue DPD200141627.

The other problem will have to wait till next week.

I really appreciate your reporting these problems to us and wish that you weren't encountering so many issues!

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

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.