Thomas Koenig <tkoenig at gcc dot> changed:

           What    |Removed                     |Added
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2018-03-02
                 CC|                            |pault at gcc dot,
                   |                            |tkoenig at gcc dot
     Ever confirmed|0                           |1

--- Comment #1 from Thomas Koenig <tkoenig at gcc dot> ---
This has to be one of the stranger bugs I have encountered...

It appears that the bug depends on the alphabetical ordering
of the type names. So, replace DerivedType in your code
by anything (such as "t2a") that comes later in the alphabet
than t2, the code compiles and runs fine.

Now, replacing DerivedType with t0 and t3, respectively, and
comparing the assembly dumps, shows some significant difference.

The t3 version has, right at the top

        .file   "a.f90"
        .globl  __m_MOD___def_init_m_T3
        .section        .rodata
        .align 4
        .type   __m_MOD___def_init_m_T3, @object
        .size   __m_MOD___def_init_m_T3, 4
        .zero   4
        .globl  __m_MOD___vtab_m_T1
        .align 32
        .type   __m_MOD___vtab_m_T1, @object
        .size   __m_MOD___vtab_m_T1, 64

and the t0 version (which does not work) has

        .file   "a.f90"
        .globl  __m_MOD___def_init_m_T0
        .section        .rodata
        .align 4
        .type   __m_MOD___def_init_m_T0, @object
        .size   __m_MOD___def_init_m_T0, 4
        .zero   4
        .globl  __m_MOD___vtab_m_T0
        .align 32
        .type   __m_MOD___vtab_m_T0, @object
        .size   __m_MOD___vtab_m_T0, 64

so whatever the def_init_m data structures are supposed to point to,
they appear to point to something wrong if things are out of
alphabetical order.

Wow, this has to be among the top 2% in weird gfortran bugs.

Reply via email to