Debugging and PR87352

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging and PR87352

Jeremy Sanders
Dear developers

As I've hit a number of gfortran bugs (PR87542 and probably PR56471 when
I tried to workaround it), I thought I would dig into the source code of
gfortran. It's quite difficult to debug given the complex structures
which are passed around. Are there any functions to print some of the
gfc_ structures, e.g. gfc_symbol, gfc_expr, gfc_namespace, gfc_code...?

For PR87542, if there is a declaration like this

module testmodule
   use iso_fortran_env
   implicit none
   public

   type :: evtlist_type
      real   (kind=real64), allocatable, dimension(:) :: p1
      real   (kind=real64), allocatable, dimension(:) :: p2
      ! add more entries here to observe N**2 behaviour
   end type evtlist_type

   type :: evtlistlist_type
      type(evtlist_type)  :: evtlist(1:1)
   end type evtlistlist_type

contains
end module testmodule

gfortran makes ~N**2 invocations of structure_alloc_comps, where N here
is 2. If you add more of the allocatable arrays to evtlist_type then N
increases. This leads to huge code and compile time bloat (scaling as
N**2), where each member is checked whether it is allocated and then
freed if it is not N times.

I'm guessing this is something to do with the logic in
generate_finalization_wrapper and finalize_component. If I comment out
the loop part of finalize_component, then the excess finalizers are not
added. Unfortunately my understanding of the code isn't complete yet -
hence my wondering whether it's possible to dump out some of the gfc
data structures to the screen.

Thanks

Jeremy Sanders
(please CC me as I'm not on the list)
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and PR87352

Steve Kargl
On Sun, Mar 24, 2019 at 06:35:59PM +0100, Jeremy Sanders wrote:
> Dear developers
>
> As I've hit a number of gfortran bugs (PR87542 and probably PR56471 when
> I tried to workaround it), I thought I would dig into the source code of
> gfortran. It's quite difficult to debug given the complex structures
> which are passed around. Are there any functions to print some of the
> gfc_ structures, e.g. gfc_symbol, gfc_expr, gfc_namespace, gfc_code...?
>

See https://gcc.gnu.org/ml/fortran/2019-02/msg00171.html

> (please CC me as I'm not on the list)

You should fix this problem. :-)

--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and PR87352

Thomas Koenig-6
In reply to this post by Jeremy Sanders
Hi Jeremy,


> As I've hit a number of gfortran bugs (PR87542 and probably PR56471 when
> I tried to workaround it), I thought I would dig into the source code of
> gfortran. It's quite difficult to debug given the complex structures
> which are passed around. Are there any functions to print some of the
> gfc_ structures, e.g. gfc_symbol, gfc_expr, gfc_namespace, gfc_code...?

For just this case, there is a short article on the gcc wiki:

https://gcc.gnu.org/wiki/GFortranHacking

If you would like to have additional functions for debugging
gfortran data structures, just give us a heads-up - those are
quite easy to add, and do not impact user code.

Hope this helps, please do not hesitate to ask again if you need
anything.

(If you're developing a patch, have you considered getting a copyright
assignment?  We need that to incorporate "large" changes, but there
is of course room for interpretation of what that means).

Regards

        Thomas
Reply | Threaded
Open this post in threaded view
|

Re: Debugging and PR87352

Jeremy Sanders
Hi Thomas

On 24/03/2019 19:40, Thomas Koenig wrote:

> For just this case, there is a short article on the gcc wiki:
>
> https://gcc.gnu.org/wiki/GFortranHacking
>
> If you would like to have additional functions for debugging
> gfortran data structures, just give us a heads-up - those are
> quite easy to add, and do not impact user code.

Thanks - I'll have a look. I might learn something!

> Hope this helps, please do not hesitate to ask again if you need
> anything.
>
> (If you're developing a patch, have you considered getting a copyright
> assignment?  We need that to incorporate "large" changes, but there
> is of course room for interpretation of what that means).

I signed a copyright form for the FSF some time ago as I was thinking
about working on gcc, but didn't in the end. Maybe I should check it is
in their records.

Best wishes

Jeremy

(Now on the mailing list)