https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84674
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-03-02
CC| |pault at gcc dot gnu.org,
| |tkoenig at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
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"
.text
.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
__m_MOD___def_init_m_T3:
.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"
.text
.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
__m_MOD___def_init_m_T0:
.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.
