https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
--- Comment #15 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> --- Hi Thomas, I had come to the conclusion that the optimizer is screwing up somehow and was going to suggest testing -fno-inline. Your splitting the files was definitely the smoking gun. It's weird, is it not, that it should be target specific? Who is the guru that we should be appealing to? Thanks for working on this. Paul On Sun, 23 Jun 2019 at 20:49, tkoenig at gcc dot gnu.org <gcc-bugzi...@gcc.gnu.org> wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813 > > Thomas Koenig <tkoenig at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Component|fortran |rtl-optimization > > --- Comment #14 from Thomas Koenig <tkoenig at gcc dot gnu.org> --- > So, the code of actually calling the procedure seems to be correct. > (It loads the address of the procedure pointer, then loads > the address from there, and branches). > > What appears to be wrong is that the subroutine fs, which assigns > the address of c to the procedure pointer, is never executed. > > Data point: -fno-inline restores the correct behavior. > > In the .optimized dump, the relevant lines are > > MEM[(struct s &)_7].i = 99; > c_ = c; > c_.5_12 = c_; > rhs.2 = c_.5_12 (); > > and it seems tat the statement > > c_ = c; > > is somehow eliminated later. > > Ouch, yes, I think I see this now (after some debugging). > > This > > # proc_ptr_51.f90:35: res => c_() > addis 10,2,.LC1@toc@ha # tmp142,, > ld 10,.LC1@toc@l(10) # tmp142,, tmp142 > > loads the contents of LC1 (where the procedure > pointer resides) into r10. > > This > > # proc_ptr_51.f90:26: c_ => c ! This used to ICE > addis 9,2,__f_MOD_c@toc@ha # tmp141,, > # proc_ptr_51.f90:30: end module f > li 8,99 # tmp139, > # proc_ptr_51.f90:26: c_ => c ! This used to ICE > addi 9,9,__f_MOD_c@toc@l # tmp141, tmp141, > > puts the address of __f_MOD_c into r9 (and loads another > value in the meantime). > > Next lines are > > # proc_ptr_51.f90:33: allocate (tgt, source = s(99)) > addis 7,2,.LANCHOR0+8@toc@ha # tmp178,,, > addi 30,30,32 # tmp172, tmp171, > # proc_ptr_51.f90:30: end module f > stw 8,0(3) # MEM[(struct s &)_7].i, tmp139 > > These lines are unrelated. > > # proc_ptr_51.f90:35: res => c_() > ld 12,0(10) # c_, c_ > > This loads the contents of the procedure poitner into r12. > > # proc_ptr_51.f90:26: c_ => c ! This used to ICE > addis 10,2,.LANCHOR1@toc@ha # tmp179,, > # proc_ptr_51.f90:33: allocate (tgt, source = s(99)) > std 30,.LANCHOR0+8@toc@l(7) # tgt._vptr, tmp172 > # proc_ptr_51.f90:26: c_ => c ! This used to ICE > std 9,.LANCHOR1@toc@l(10) # c_, tmp141 > > This (if I am not mistaken) stores the contents of r9 into the > procedure pointer, but it is too late, because this > > # proc_ptr_51.f90:35: res => c_() > mtctr 12 #, > > jumps to the NULL pointer. > > Interesting question: Why is the store done too late? The tree > dumps look OK; the problem also does not occur if the > call to fs is replaced by a simple pointer assignment. > > So, I am going to guess and say this is probably an RTL problem. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
