[PATCH, Fortran] Four small DEC extensions
Jerry DeLisle
jvdelisle@charter.net
Fri Oct 14 17:02:00 GMT 2016
On 10/14/2016 02:53 AM, Jim MacArthur wrote:
> On 12/10/16 13:30, Fritz Reese wrote:
>> Here I submit for review four small extensions to the GNU Fortran
>> frontend for compatibility with legacy code. I figure it might be a
>> nice change of pace from my larger patches. Never fear, for I have
>> more large patches to come, which I will continue to submit
>> one-at-a-time.
>>
>> Each extension is enabled with its own compile flag, and each are
>> enabled along with -fdec. They are fairly self-explanatory.
>>
>> 1. [-fdec-feed] Treat form feed characters as whitespace.
>> 2. [-fdec-type-print] Treat TYPE as an alias for PRINT where applicable.
>> 3. [-fdec-loc-rval] Allow %LOC() as an rvalue, equivalent to using the
>> LOC() intrinsic.
>> 4. [-fdec-logical-xor] Enable .XOR. as a logical operator.
>>
>> Feel free to comment on/question/approve each patch individually as
>> desired. They are attached as sequential patch files for ease of
>> review. Bootstraps & regtests on x86_64-redhat-
>> linux. OK for trunk?
>>
>> ---
>> Fritz Reese
>>
>
> I'm not in a position to approve of these patches but the .XOR. one is very
> similar to one we've had in a private branch for a while so I'd be very happy to
> see that in trunk.
>
> The TYPE as PRINT problem is one we managed to fix by automatic replacement in
> the source code. It's not quite as simple as sed, because replacing TYPE with
> PRINT pushes some lines over 72 characters. Our tool to do this - not a
> particularly polished one - is at
> https://github.com/CodethinkLabs/fortrantools/blob/master/type-to-print.py in
> case that's of use to anyone. No objections to your patch being added to trunk,
> of course.
>
> Jim
You bring up a good point about exceeding the 72 limit. I do think we have a
flag to extend that limit if one wants to use it, but then you run into code
that uses index numbers and such in the columns after 72.
This headache alone is probably sufficient to include TYPE as long as we don't
break the other newer TYPE. Also if Intel supports it, we should as well.
Jerry
More information about the Fortran
mailing list