https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
--- Comment #4 from ygal klein <ygalklein at gmail dot com> --- (In reply to Jürgen Reuter from comment #3) > I think that indeed this is not something the compiler needs to do as > expected, as it is an aliasing problem. > In the advance TBP you are calling again the init routine. The init > routines sets the value of this%var1 to the argument with which it is > called. In this%advance you are calling the init routine with the > argument this%var1. However, in the init routine, the struct1 type > is intent(out), so it is not guaranteed that the value of struct1%var1 > is accessible when calling the init routine from an earlier initialization > of that type. That is the aliasing problem: advance calls > the init routine, the init routine creates a new instance of struct1 > and you are not guaranteed that you can access the struct1%var1 component. > There are several ways out: > (1) define this in the init routine as intent(inout), very unusual for > an initializer, but then gfortran does what you expect > (2) define a global instance of struct1 in the module, e.g. > type(original_struct), save, public :: struct_global > and in advance then call the (before initialized) > this%init(struct_global%var1) Thank you for the reply. After posting the bug report - I saw that implementing (inout) as your number 1 suggestion - dodges the problem - though as you mentioned having inout for this in an init routine is somewhat unnatural. The 2nd suggestion is something that I was trying to avoid in the first place - i.e copying a whole type (this minimal example is a small type - but originally it is a type with a lot of instances and procedures) In fact - I could have had advance as a function that returns a type - but then I would be paying the price of copyin assignment of a big type. Anyway - you conclude that gfortran is behaving as it should and that the fact that ifort works - is somewhat a coincidence?
