Re: [Patch, Fortran] PR fortran/35681: First part, fix ELEMENTAL dependency handling for MVBITS

[Daniel Kraft <d@domob.eu>]

Paul Richard Thomas wrote:
> Daniel,
> 
> I'm a bit pole-axed with the daytime job right now, so my reply must be short.
> 
> I have to say that I'me really puzzled about this:
> 
>> 6) I could not find a test to verify this (not even one that uses
>> gfc_conv_elemental_dependencies) in a quick trial, but I believe the
>> handling of the temporary there was wrong, in that it was free'd (if
>> allocated on the heap) *before* it was used with internal_unpack, because
>> gfc_trans_create_temp_array added the temporary clean-up code to se->post
>> and the unpack-call was added to se->post later.  In my opinion, this is
>> some rather general problem with how post-commands are usually added to
>> other post blocks; shouldn't they be added to the top usually rather than to
>> the bottom, to get some sort of "nested" scope with inner most pairs of
>> pre/post?  Well, for now I changed this behaviour inside
>> gfc_conv_elemental_dependencies, which corrected problems I got with MVBITS
>> tests.
>>
> 
> The code from the first assignement in elemental_subroutine_3.f90,
> which was the first test of this function gives:
> 
...
> 
> As you can see, atmp.3.data is assigned to the stack but it is not
> freed either before or after being unpacked.  This code, at least is
> OK.

Indeed it is, but it would not have been (at least I think so) if the 
array was allocated and not on the stack; however, as I wrote, I did not 
manage to build a test that really produced invalid code this way (not 
even one that used gfc_conv_elemental_dependencies...)

Thanks for your comments, they are very welcome :)

Yours,
Daniel

-- 
Done:  Arc-Bar-Cav-Rog-Sam-Val-Wiz
To go: Hea-Kni-Mon-Pri-Ran-Tou