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

            Bug ID: 80477
           Summary: Polymorphic functions (thus operators) generates
                    memory leaks
           Product: gcc
           Version: 6.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stefano.zaghi at cnr dot it
  Target Milestone: ---

Created attachment 41241
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41241&action=edit
Code test to raise the memory leaks

Dear all,
I faced with a possible serious bug: polymorphic functions (necessary to define
polymorphic operators in OOP programs) generate memory leaks making OOP program
not feasible.

In the attached example "polymorphic_operators_memory_leaks.f90" I show the
possible bug in less than 100 lines. Essentially, the derived type "a_type_t"
defines the operators "=" and "+" in a polymorphic way (in order to allow
"a_type_t" to be extended while all other "agents" using "a_type_t" do not need
to be changed, OOP). The assignment operator does not create memory leaks
because it is subroutine that does not allocate temporary. On the contrary, the
operator "+" is a function that allocates a temporary: this temporary generates
the memory leaks because it is not correctly destroyed after its usage.

I checked the above conclusion with "valgrind" and it confirms that the "+"
operator (function) generates the leaks. Note that the same code compiled and
run with Intel Fortran (17.0.2) does not generates memory leaks and it works as
expected. Moreover, is the "+" operator/function is modified disallowing
polymorphic (namely changing "class(a_type_t), allocatable :: res" with
"type(a_type_t) :: res" the leaks disappear, thus I could conclude that the
leaks are generated only for polymorphic function results.

A word of advice: the test is designed to point out the memory leaks
occurrences, running it your RAM will be quickly consumed! Please, be rapid to
quickly kill it before your OS start swapping on HD. To test it with valgrind I
added a little "ui": it can be executed without arguments, thus its loop will
be very long (and your RAM totally consumed) or you can pass one integer
argument and the loop will do the iterations you provided, e.g. "a.out 1" will
execute 1 iteration loop. This is written into the code comments.

Please, consider that if this is really a bug, all serious OOP programs are
indeed impossible to be done.

Thank you very much for your help.

Reply via email to