[Bug fortran/40877] memory leaks with gfc_charlen?

["burnus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #4 from burnus at gcc dot gnu dot org  2009-08-05 12:50 -------
(In reply to comment #3)
> Tobias, do you remember any of your thoughts when writing this? 

Well, they are essentially written in the patch email (linked from the PR
40383):
   http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01147.html

The test case was:
  subroutine sub(a,b)
     character(4), optional :: a, b  ! Known compile-time length
which translates into:
  sub (a, b, a_, b_)
where "a_" and "b_" are not used in the function (as the character length is
known) except for the bounds checking. In that case one needs to access the
TREE (or backend declaration) for "a_" and for "b_".

However, as "a" and "b" are the same, they share the same "cl" - and the same
backend type declaration (which is fine). Before Daniel's bounds check, the
"a_" and "b_" TREEs were generated but not anywhere saved, as they are not
needed. Daniel's patch simply added a pointer to a TREE to "cl" which points at
that hidden argument. As there is only one "cl" shared by both "a" and "b", one
could only access "b_" - that way one would effectively only check one of the
arguments (incomplete check). However, if optional arguments are involved, that
argument might be missing and "b_" is 0, which turns it into a wrong diagnostic
for "a".

One solution would be to create two "cl" - one for "a" and one for "b".
However, that would also create two type declaration TREEs even though "a" and
"b" have exactly the same type. Already at present the middle end has problems
with different TREE types for variables which have the same Fortran type. 
(Maybe I am wrong and we fixed this meanwhile and gfortran re-uses the TREE,
but I do not think so.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40877