https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 5 Dec 2018, rguenther at suse dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 > > --- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- > On Wed, 5 Dec 2018, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88304 > > > > --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > > And lastly, what tree-nested.c does in cases which don't really fail is > > pretty > > weird: > > module pr88304 > > implicit none > > contains > > subroutine f1 (x) > > integer, intent(out) :: x > > x = 5 > > end subroutine f1 > > subroutine f2 () > > integer :: x > > call f3 > > if (x .ne. 5) stop 1 > > contains > > subroutine f3 > > call f1 (x) > > end subroutine f3 > > end subroutine f2 > > end module pr88304 > > > > The original > > x = {CLOBBER}; > > is replaced here with: > > integer(kind=4) D.3863; > > > > D.3863 = {CLOBBER}; > > CHAIN.3->x = D.3863; > > I guess we want to drop those from the IL instead as well. > > Heh, yes. Or convert them to > > D.3863 = CHAIN.3->x; > *D.3863 = {CLOBBER}; > > but not sure if those will ever end up being useful. Might be in case the function is inlined if we manage to turn it back to x = {CLOBBER}; ?
