Assignment procedure called in UDTIO for no apparent reason

In the code (that I try to attach, since it's about 200 lines), I am reading data from a file and experienced mysterious crashes.

In my reduced example, a line of data is like this :

20010101,  2.3456,   2222222.22#20010202,  2.0123,   2323232.32#                                    !

Each line corresponds to one item of type T_LISTE, which contains a dynamic array of type T_VAL. Each T_VAL contains a date and two real values, separated by comma's in the file. The T_VAL's in the file are separated by "#".

Each line is read with a DT format, and the defined read for T_LISTE reads the line into a character variable, counts the "#" and then breaks the string up into parts that correspond to one T_VAL. That substring is then read, using a DT format for the date, as we have a user defined type to handle dates.

The crashes occur because of a behavior in the date type that I cannot explain.

In the module that defines the date type, I have :

    type t_date
        integer :: j
        integer :: m
        integer :: a
    contains
        procedure :: r_fmt
        procedure, private, pass(expr) :: c_ass_d !<-- comment here
        procedure, private             :: d_eq_d
        procedure, private             :: d_ne_d
        generic   :: read(formatted)  => r_fmt
        generic   :: assignment(=) => c_ass_d !<-- and comment here
        generic   :: operator(==) => d_eq_d
        generic   :: operator(/=) => d_ne_d
    end type t_date

On a read of a T_LISTE, the program tries to call c_ass_d (which assigns a date to a character variable) which than crashes because there is no character variable. If I comment the lines defining the assignment the code works as intended.

Of course our real types are much more complex than this, and I cannot remove the assignment of date to character. I do not understand however why  the assignment is called in the first place.

As attached the code compiles with ifort 16.0.0.110. Version 15.0.4.0  shows the same behavior, however one has to remove "private" from the 3 bound procedures in t_date, as otherwise v15 throws an error.