[patch, fortran] Implement constant-folding for TRANSFER intrinsic.

[Paul Thomas]

Tobi,

Please find enclosed a patch that I believe remedies that which was 
wrong....
>
>>
>> Or do you merely mean that the "NULL" part should be omitted, and the 
>> earlier version of it should be written as "!size" rather than as 
>> "size != NULL"?  That makes sense.
>
> The latter, sorry for the confusion.
done
>
> My suggestion may also break with zero source_sizes, so I think we 
> should stay with yours.
indeed
>
>>> What about targets with different character sets?
>>
>> They are currently hypothetical; even the S390 is only currently 
>> supported in an ASCII configuration as far as I can tell.
>>
>> It's a valid concern beyond that, but I'm not sure what to do with it.
>
> I thought the S390 used EBCDIC unconditionally, if that's not the 
> case, I agree that it's not a real problem.
You are right... I have tried to forget EBCDIC for a long time.... and 
S390s.  Let's wait and see if it is a real problem.  The testcase 
compares transfers made via the front and the middle-end, so they should 
not depend on the character set.  I think that I am right in saying that 
any other form of test would not be portable.  Remember that TRANSFER is 
a very odd beast - it actually rejoices in converting one type bitwise 
to another.  Thus, anything that depends on changing characters to 
something else cannot, by definition, be character set independent.
>
>> My inclination would be to do the cosmetic and small fixes to this 
>> and go ahead and commit it and then work on the 
>> alternate-character-set hypotheticality and the derived-type spacing 
>> stuff in follow-up patches, since AFAIK this doesn't cause anything 
>> to break that worked previously.  But that's not a strong 
>> inclination, and I'll let Paul and FX make the call on that.  :)
I agree.
>
> I think we should assert that we're not dealing with derived types, 
> since otherwise we would leave the user with a potentially 
> hard-to-find error.  Apart from that, I agree with this course of action.
I have fixed derived types.  Instead of assuming that the derived types 
are packed, I have used gfc_typenode_for_spec to produce a tree type and 
then use the offset values in the components.  I believe that this is 
robust.

Various other bits and pieces have been done, as you suggested - alloca, 
MAX etc., etc.

I have added some complex tests but have not yet got around to the 
REAL(10 + x) tests.  I propose to do a transfer_simplify_3.f90 just as 
soon as I have a moment.

Unless somebody objects, I will commit to trunk tomorrow morning.

Thanks for the review, Tobi

Paul

PS I wrote a skeleton for this patch that was completely target 
dependent and something of an organisational disaster.  Brooks then took 
it, did the middle-end mods and cleaned up my mess.  Many thanks to 
Brooks for all of that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr18769.diff
Type: text/x-patch
Size: 28055 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070515/6b8da84a/attachment.bin>