http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
--- Comment #10 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> --- A further small remark, when the explicit interface for obs1_int is turned to a subroutine, everything works perfectly. I am homing in on this as being the source of the trouble; I suspect that the function pointer is not receiving the DEC_SIZE information. I will look tonight. On 23 February 2014 21:49, pault at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198 > > --- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> --- > Hi Tobias, > > I need to walk away from this one for 24 hours. > > I have established this chain: > (i) We start building decay_t; > (ii) During which we have to build decay_gen_t (from trans-types.c:2456); > (iii) Followed by decay_term_t; > (iv) Which has a decay_t as its only component; > (v) Since this is in the process of being built, what is retruned is the > backend_decl without any of the fields. Thus the size cannot be determined; > (vi) For reasons that I cannot see, since this component is a pointer, > indeterminate size this propagates back to the size of the decay_gen_t > component in decay_t; and > (vii) This I suppose but have not confirmed, clobbers the initialisation of > the > vtable. > > This latter is surmise, on the basis that changing the 'term' field to a > pointer still causes the size problem but the ICE goes away. The programme > even > executes! > > I cannot see why there is a problem in estimating the size, since the relevant > components are either allocatable or pointers - thus the size can be > determined. > > Cheers > > Paul > > -- > You are receiving this mail because: > You are on the CC list for the bug.
