MVBITS again

[Daniel Kraft]

Hi Paul,

thanks for your help here so far!

Paul Richard Thomas wrote:
>> While this now creates a temporary for the output array, the output is still
>> wrong as MVBITS wants an INTENT(*INOUT*) argument and the created temporary
>> does not take over the initial values on creation.  It seems to me like a
>> bug in gfc_conv_elemental_dependencies, as this should indeed be done for
>> INTENT(*INOUT*), shouldn't it?  So my question, do you think it's ok to fix
>> this there in general or is it done the way it is at the moment for some
>> reason I'm missing at the moment, so that I must not "fix" this behaviour?
> 
> I don't see why not.  It's not a bug because, until now, only
> INTENT(OUT) arrived there; from interface assignements.

I already suspected this, and investigated here a bit.  So far I've come 
up with an experimental solution of using internal_pack for copying the 
data into the temporary.  I tried to manipulate internal_pack such that 
it can optionally pack into a buffer passed as argument, not return the 
packed data.  This worked and should be possible to change (and I 
believe this new internal_pack functionality could be generally useful) 
and compiled FX's test from comment #1 without parentheses fine. 
However, I'm not sure if we want to change the library that way now (and 
at least we should version the new internal_pack function, right?

If it would be fine to do so and someone can give me some hints on how 
to do the versioning, I should be able to post a patch to fix this half 
of PR 35681 in a few days.

On the other hand, I also tried to do front-end only changes such that I 
can use the existing internal_pack as-is, by extending the 
gfc_trans_create_temp_array method to allow initializing the created 
temporary to some value (as we want here) and, if that's the case, call 
internal_pack and let it allocate and return the storage to use; I'm not 
completely sure about the details and I got it all right so far, but in 
general this seems to work, also.

The only problem is that internal_pack does only allocate a new array 
and pack into it if the argument is not already packed in which case 
that one is simply returned.  This does not make much sense to me (from 
a certain POV at least); how should be caller know if he is to 
deallocate the memory when he's done?  Can I somehow force internal_pack 
to allocate and copy?  Or at least do I have a way to find out if the 
array was already packed to I can do the allocation and copying myself?

I believe both solutions should work more or less equally well and both 
have certain advantages (making some functionality available that could 
be interesting in general, like the temporary initialization?) and 
drawbacks (like the ABI breakage / need for versioning).  What do you 
think I should go for?

Thanks,
Daniel

PS: Jerry and Tobias, I CC'ed you because I think those library/ABI 
related things could be interesting for you, too, and you could probably 
help here with comments.

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