Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

On default initialization

John4
Valued Contributor I
827 Views

Hi,

Even though, in light of recent threads, the code is not useful, I was wondering: why, in the following code, the compiler reports missing initialization, when the field is already initialized?

module mod1

    type :: t1
        integer :: i = 0
    end type

    type :: t2
        type(t1) :: a
    end type

contains
    subroutine do_something()
        type(t2), allocatable :: t(:)

        allocate (t(1:0))
        t = [t, t2()]
    end subroutine

end module mod1

The definition of the type of the component is always available (as opposed to what might happen with the interface of a function or subroutine), so it could just check its initialization as well (and save the extra "= t1()" required in the declaration of the component). Or am I missing something obvious?


 

0 Kudos
6 Replies
Steven_L_Intel1
Employee
827 Views

An interesting case. I'm used to seeing issues like this with extended types, but that's not what we have here.

The standard says, regarding structure constructors:

C491 (R455) A component-spec shall be provided for a nonallocatable component unless it has default initialization or is inheritance associated with a subcomponent of another component for which a component-spec is provided.

Inheritance association is not relevant as this is not an extended type.

In your example, component a doesn't have default initialization. It is true that the type of a does have such for its components, but the standard doesn't consider that - at least I can't find words to say that it does.

I note that gfortran accepts your source without comment. I am going to check with the standards committee members just to make sure my understanding is correct.

0 Kudos
Steven_L_Intel1
Employee
827 Views

On further research, this is our bug and I will let the developers know. a does indeed have default initialization due to the subcomponents being initialized. Issue ID is DPD200361914.

0 Kudos
John4
Valued Contributor I
827 Views

Hi Steve,

The definition of t2 doesn't involve any structure constructor, so the constraint you mentioned (C492, in my copy of the standard) doesn't apply ---it applies in line 17, though.

In paragraph 7 of section 4.5.4.6 of the standard, I read:

7 A subcomponent (6.4.2) is default-initialized if the type of the object of which it is a component specifies default
initialization for that component, and the subcomponent is not a subobject of an object that is default-initialized
or explicitly initialized.

Which, to me, implies that the default initialization should apply for a%i, as you just confirmed. Thanks for clarifying the issue.

 

0 Kudos
Steven_L_Intel1
Employee
827 Views

I wasn't concerned with the definition of t2, just the structure constructor. The text you cite is not quite relevant, it is sort of the reverse direction. It's paragraph 8 which has the appropriate text:

A type has default initialization if component-initialization is specified for any direct component of the type. An object has default initialization if it is of a type that has default initialization.

0 Kudos
John4
Valued Contributor I
827 Views

The thing is, the error goes away if I define t2 as:

    type :: t2
        type(t1) :: a = t1()
    end type

So, to me, it means that the compiler is only checking if the initialization of the (non-allocatable) components in t2 is explicit ---that's why, in my original post, I suggest that the compiler could check the definition of t1 as well, to save on the extra " = t1()".

Anyway, it seems like it's still a bug.

0 Kudos
Steven_L_Intel1
Employee
827 Views

What the compiler is missing is the nested property of default initialization. It's a simple thing we overlooked and will fix it.

0 Kudos
Reply