https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #25 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Mon, Nov 06, 2023 at 03:34:42PM +0000, trnka at scm dot com wrote: > > If expr->where is pointing to NULL, then something is definitely not > > set up correctly or your code is now going through a different code > > path in the compiler. > > Sorry for the delay with testing this, I was busy with other more pressing > tasks. No problem. I have very limited time to look at gfortran bugs and yours caught my eye. > It's not that expr->where would be NULL completely, but its components (nextc > and lb) are both NULL. Sorry about that. I did mean to say the components not just expr->where. In any event, the locus is clearly not correct. > > If this is related to setting up the artificial __final_* procedure, > > then it might be missing properly setting the locus. This patch > > simply sets the locus of the artificial procedure and its arguments > > to that of the derived symbol. This might prevent the ICE, but > > lead to a bogus error message. Can you test this? > > Tested, does not change a thing. The error does not seem to directly have > anything to do with the __final_*, but with building the __vtab_* using a > structure constructor, which is likely happening at a different place as > a side effect of Paul's finalization improvements. Bummer. I was hoping that it would give a better pointer to where gfortran needs to handle the locus. > As this seems to be a different (although possibly related) issue, > I have created PR112407 for further follow-up and posted my new > observations in there. I saw the new PR. Thanks for the in depth analysis. In setting up the constructor for a __vtab_* (an internal symbol), we likely need to ensure the locus is properly set in each list member.
