Dear Tobias, I applied your patch and have the following comments:
On Fri, Apr 29, 2011 at 11:46 PM, Tobias Burnus <bur...@net-b.de> wrote: > Dear all, > > gfc_trans_deferred_vars is a bit of a mess; there is first a block which > handles function results of the type proc_sym->result == proc_sym. > Afterwards, deferred variables - local, dummys, and proc_sym->result (!= > proc_sym) are handled. > > The problem is that for allocatable results (esp. of CLASS type) and for > deferred-length strings, the same initialization has to happen as for > function results. Yes, I agree that this has become something of a mess. > > Consequence: There is code partial duplication - and some code should be > duplicated, but is not; that causes the issue with the current code. > > Attached patch tries to fix that; it fixes Arjan's wrong-code issue and it > also reduces the code size; however, I do not think that it makes the code > very readable. I don't think that it makes it less readable :-) > > What do you think? How can this be improved? Or should the patch be > committed as is? (The patch was regtested on x86-64-linux.) Originally, gfc_trans_deferred_vars had very little code within the conditional blocks - mainly, there were calls to appropriately named functions. The naming was intended to expose the logic. I would suggest that you do likewise. It's something of a no-brainer as far as its implementation is concerned and it certainly makes the logic stand out more. There are various other parts of ~/gcc/fortran that could stand the same treatment! On the wrong-code issue: I could not see any difference in behaviour using your testcase between trunk with your patch and 4.6.0 without. I have yet to return to Arjen's original and will report when I have done. Anyway, thanks for looking at the PR and cleaning up gfc_trans_deferred_vars. Paul
