This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran] More clean-up with try-finally


Tobias Burnus wrote:
Dear Paul,

Paul Richard Thomas wrote:
I think this line can go.
I do not think that I agree.

I am hard put to do it right now but I rather think that it must be
possible to generate an integer-scalar-expression that generates a
post block. It certainly does no harm to leave it in :-)

Thinking about it again, I agree: One needs to take care of se.post. However, if one simply adds the previous line, the result for the example below is as follows. First, one returns and then one frees the memory:

    return __result_bar;
    {
      void * D.1566;

      D.1566 = (void *) pstr.0;
      if (D.1566 != 0B)
        {
          __builtin_free (D.1566);
        }
    }

which doesn't make sense. (Ditto for the old code: The free came after
the "goto __return".) Thus, removing the line does neither harm nor
improve the situation. The real fix is to ensure that the clean up of
"se.post" comes before the "return".

Yes, I also agree. Of course, we could build another try-finally there to counter the problem, if se.post is not empty. I can add this, if you agree that it's a reasonable solution. But I've no idea what to do else.


BTW, I remember when doing other work at trans-*, that se.post was not used really symetricaly to se.pre at some places (e.g., also just ignored).

Daniel

--
http://www.pro-vegan.info/
--
Done:  Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz
To go: Hea-Kni-Mon-Pri


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]