https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106606
Andre Vehreschild <vehre at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vehre at gcc dot gnu.org
--- Comment #6 from Andre Vehreschild <vehre at gcc dot gnu.org> ---
Created attachment 58986
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58986&action=edit
WIP patch
Hi Paul,
I took a look and after same stabbing around in the dark, figured that a
derived type that has been resolved already should not be resolved again. I
therefore decided to use the gfc_symbol::mark to figure, if the type has been
setup already. This worked remarkably well. Unfortunately does the current
patch regress in select_type_4.f90 (the only regression). I am preparing to go
on holiday, so I can't spent more time on this.
Oh, btw, with your patch the runtime crash is due to the root%_data =
__builtin_malloc(4); which is clearly to less memory to accommodate two
class-_datas and _vptrs as well as the int. I assume that by bad luck you ended
up overwriting your roots%_vptr.
Feel free to use the attached patch as start to fix this finally. What I don't
get yet is, why there is a need for pointer and proc_pointer components to be
excluded from not re-resolving an existing type. Any idea? May be the issue
with select_type_4 is by some other location making a similar assumption.
The reason why I added the coarray-check is, that this may copy the type for a
different corank, which unfortunately is encoded in the type name.
So long. I will be sporadically online only in the next three weeks. Have fun.
- Andre
