------- 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