https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644
--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Fri, Oct 20, 2023 at 03:13:06PM +0000, aluaces at udc dot es wrote: > Ok, indeed they were some warnings. I had to use &gfc_current_locus, as you > suggested, so now all of them are pointed at the end of the file. Yeah, this is one of the places I though it would point to. The other place would be the first line in the file. Either way, it is bogus location. > Yes, I am using OOP: we have a "states" class that has its assignment and copy > methods. Those are the ones that I think that they are called implicitly by > the compiler, and gfortran is struggling to point exactly where. Thanks for confirmation. When a 'class' entity is involved, gfortran may generate an internal entity to resolve the class. Unfortunately, the location information is sometimes not properly propagated, and it seems you've found one of those places. > I think now I may be able to get a minimal case for aiding solving this bug. > Let me see if I can. This would be much appreciated. BTW, as it seems you know your way around gdb, if you have a breakpoint set where you found expr->where contained NULL pointers, you can do (gdb) p *expr to dump the structure. You'll see *expr->ts.type == BT_CLASS (basic type CLASS). IIRC, *expr->symtree->name will have the name of the entity. If it starts with __vtab (or _vtab), it is an internally generated symbol.
