[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Thu, Jan 26, 2023 at 02:56:02AM +0000, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
> 
> --- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
> I found that the attached patch does not work.  At the point of assertion many
> of the other functions to free memory have null pointers which leads to
> segfaults all along the way.
> 
> The following approach appears to work, however, obviously there is a lot of
> memory left not freed, so we would rely on the OS to clean it up. Maybe this is
> ok, not sure.
> 

I think that it is ok.  A lot of the gfortran FE code
assumes that it is dealing with a conforming Fortran
program.  Many failing test cases are constructed from
invalid Fortran code (see any of a number of Gerhard's PR),
which takes torturous paths through the Fortran FE.

The only other option is to check the pointers, but this
is going to get ugly with some of the structs we have.

Something like 

   if (a->b->c->d) free(...)

becomes

   if (a && a->b && a->b->c && a->b->c->d) free(...)