DEC Extension Support for gcc-4.8.3

DEC Extension Support for gcc-4.8.3

[Fritz Reese]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

All,

I have been getting a lot of requests to release the patches I have
for gcc-4.8.3, since many systems (i.e. RHEL/CentOS 6.x) still ship
with that version of the compiler suite. I thought it would be nice to
post those changes on the mailing list for all to see, though all the
changes may not end up in the baseline. I'm still planning on breaking
up most of these changes into individual patches and submitting them
for review against trunk, but this patch may be useful to those who
are impatient. The patched 4.8.3 clears all regtests and includes its
own testsuite. If you have problems with this patch please message me
directly, do not pollute the gcc/fortran mailing list. I don't intend
to publicly support updates to this patch set. Any updates I do will
make their way into the patches I submit on trunk in due time.

With that said, attached is the monolithic patch which contains ALL of
the DEC extension support I have implemented into 4.8.3.  Most of the
changes can be found by digging through the info/man pages of the new
Fortran compiler. Here is a summary of all new compiler options:

 -finit-derived Enable initialization of derived-type (and structure)
variables, as with -finit-local-zero and -finit-* (not a DEC extension
per se)
 -Wargument-mismatch/-Wno-argument-mismatch Enable/disable warnings
for type/rank mismatches between formal parameters and actual
arguments
 -fdec Enable all options listed below, as well as -fdollar-ok and
-fd-lines-as-comments
 -fdec-member-dot Enable dot ('.') as a member accessor.
 -fdec-structure Enable support for STRUCTURE, RECORD, UNION, and MAP.
Implies -fdec-member-dot
 -fdec-intrinsic-ints Enable B/I/J/K kind variants for integer intrinsics
 -fdec-bitwise-ops Allow logical operations on integers, and perform
the equivalent bitwise operation
 -flazy-logicals Disable errors and warnings when using integers as
conditional expressions. Implies -fdec-bitwise-ops
 -fdec-extended-int Enable the DEC extended integer constant format "base#value"
 -fdec-io Enable DEC extended IO syntax, including READONLY, SHARED
and CARRIAGECONTROL specifiers
 -fdec-static Enable STATIC and AUTOMATIC as attributes specifying
storage location
 -fdec-logical-xor Enable the logical .XOR. function (same as .NEQV.)
 -fdec-math Enable extra math intrinsics, such as COTAN and
degree-valued trig functions
 -ffeed Treat form feed ("\f") characters as whitespace in the source
 -ftype-print Interpret TYPE as an alias for PRINT when possible

Enjoy!

---
Fritz Reese

[-- Attachment #2: gcc48-for-0011.patch.gz --]
[-- Type: application/x-gzip, Size: 111843 bytes --]

Re: DEC Extension Support for gcc-4.8.3

[Bernhard Reutner-Fischer]

On March 4, 2016 5:19:49 PM GMT+01:00, Fritz Reese <fritzoreese@gmail.com> wrote:
>All,

> -fdec Enable all options listed below, as well as -fdollar-ok and
>-fd-lines-as-comments

If you happen to have a DEC Compiler lying around, I'd be interested in how they handle implicit $

See post scriptum in
https://gcc.gnu.org/ml/fortran/2007-01/msg00060.html

Thanks,

Re: DEC Extension Support for gcc-4.8.3

[Fritz Reese]

On Sat, Mar 5, 2016 at 5:08 PM, Bernhard Reutner-Fischer
<rep.dot.nop@gmail.com> wrote:
>
> If you happen to have a DEC Compiler lying around, I'd be interested in how they handle implicit $
>
> See post scriptum in
> https://gcc.gnu.org/ml/fortran/2007-01/msg00060.html

It seems ifort treats a leading '$' implicitly as an integer.

---
Fritz Reese

Re: DEC Extension Support for gcc-4.8.3

[Bernhard Reutner-Fischer]

On Sat, Mar 05, 2016 at 05:37:37PM -0500, Fritz Reese wrote:
> On Sat, Mar 5, 2016 at 5:08 PM, Bernhard Reutner-Fischer
> <rep.dot.nop@gmail.com> wrote:
> >
> > If you happen to have a DEC Compiler lying around, I'd be interested in how they handle implicit $
> >
> > See post scriptum in
> > https://gcc.gnu.org/ml/fortran/2007-01/msg00060.html
> 
> It seems ifort treats a leading '$' implicitly as an integer.

Supposedly setting the default type works too with ifort.

I was curious about the behaviour of the DEC compiler, though.

cheers,

Re: DEC Extension Support for gcc-4.8.3

[Tim Prince]

On 3/5/2016 7:09 PM, Bernhard Reutner-Fischer wrote:
> On Sat, Mar 05, 2016 at 05:37:37PM -0500, Fritz Reese wrote:
>> On Sat, Mar 5, 2016 at 5:08 PM, Bernhard Reutner-Fischer
>> <rep.dot.nop@gmail.com> wrote:
>>>
>>> If you happen to have a DEC Compiler lying around, I'd be interested in how they handle implicit $
>>>
>>> See post scriptum in
>>> https://gcc.gnu.org/ml/fortran/2007-01/msg00060.html
>>
>> It seems ifort treats a leading '$' implicitly as an integer.
>
> Supposedly setting the default type works too with ifort.
>
> I was curious about the behaviour of the DEC compiler, though.
>
> cheers,
>
I have a running copy of CVF from 15 years ago, in case you have a test 
case in mind.
I thought the purpose of permitting '$' was to support VMS system 
function calls, so implicit integer may make sense.  Such programs 
evidently won't be portable even if you reconcile this bit.

-- 
Tim Prince

Re: DEC Extension Support for gcc-4.8.3

[Jim MacArthur]

On 08/03/16 17:45, Jerry DeLisle wrote:
> On 03/07/2016 04:10 PM, W Spector wrote:

>> Allowing $ in variable names was an old, old, ('60s/'70s) IBM mainframe
>> extension, and maybe others of the era too.  I first encountered it in 1978 or
>> so. So definitely pre-VAX.

>
> IMHO for some of these things on legacy code, judicious use of editors like sed
> should be used on the source codes and just bring them out of the dark ages.  It
> really is not that hard.  If the code is that important then just do it.
> Hacking compilers out of laziness just does not seem right.
>
> I am not saying anyone is lazy and do not intend to offend, I fully understand
> what it is like to have over bearing workloads, but we should at least do a
> reality check.
>

We've investigated automatic transforms on our source code and couldn't 
find any way to do it with regexes, with the exception of TYPE being 
used as PRINT, which we did manage to transform quite easily. Everything 
else we've found needs more context, and some things (like UNION & MAP) 
are impossible. (If you were just talking about '$' though, I can't say 
I've encountered that).

Making the source code standards-compliant is the correct solution, no 
doubt about that. However, we have users who are paying what I imagine 
is quite a lot for proprietary compilers and so are well motivated to 
get away from them but don't feel they can fix up all their source to be 
standard compliant. Hence, we maintain a fork of GCC with our own set of 
DEC & Sun extensions which overlaps somewhat with these patches Fritz 
has sent. This is the most practical solution we've got at the moment. 
We're very happy to send in patches for these if there's a general 
consensus that legacy features are wanted.

In the meantime I'm very grateful to Fritz for producing this set and I 
will review it while testing it out on our code.

Re: DEC Extension Support for gcc-4.8.3

[W Spector]

Jim Secan <james dot secan at gmail dot com> wrote:

> ... Others, structures being the main one, also raise old memories (and not fond ones) of the Fortran committee rejecting this de-facto standard in the first place.

DEC added VAX structures in an intentionally incompatible way from the 
direction the Fortran committee was headed.  Blame should be on DEC - 
not the Fortran committee.

That said, I've dealt with some Fortran code in the past where having a 
'union' capability in derived types would have been quite helpful.  I 
was able to work around it with some clever use (read: giant hack) of 
F90 pointers, and it worked.  However if I were to revisit that project 
today, I would try really hard to use type extension to eliminate some 
of the cleverness/hackishness.

So I am not really against gfortran including VAX structures/unions - 
provided they are only enabled via special compiler flags.  I know what 
a PITA it can be in certain cases to work around not having them - 
especially when porting old code.

A number of the other VAX extensions have direct substitutions in modern 
Fortran.  Simple editing tools and shell scripts can be used to do the 
substitutions for an entire code base in a few seconds.  So I am less 
sympathetic to them.

Walter

Re: DEC Extension Support for gcc-4.8.3

[Jim Secan]

As an “end user” of this compiler and a five-decades Fortran coder I am happy to see the DEC extensions added to gfortran, particularly the structures framework.  I am, as others suggest, slowly converting old code over to use derived types, but I’d prefer to be spending my time on my day job rather than reinventing wheels.  Some things, like the $ inclusion in variable names and other musty old stuff, are definitely in the “clean it up” hopper.  Others, structures being the main one, also raise old memories (and not fond ones) of the Fortran committee rejecting this de-facto standard in the first place.

Anyway, I welcome the addition of the structures formalism to gfortran.  I don’t see it as a compiler hack as much as helpful extension.

Jim
3222 NE 89th St
Seattle, WA 98115
(206) 430-0109

On Mar 8, 2016, at 9:45 AM, Jerry DeLisle <jvdelisle@charter.net> wrote:

> On 03/07/2016 04:10 PM, W Spector wrote:
>> Tim Prince <n8tm at aol dot com> wrote:
>>> ... I thought the purpose of permitting '$' was to support VMS system function
>>> calls, so implicit integer may make sense. Such programs evidently won't be
>>> portable even if you reconcile this bit.
>> 
>> Allowing $ in variable names was an old, old, ('60s/'70s) IBM mainframe
>> extension, and maybe others of the era too.  I first encountered it in 1978 or
>> so. So definitely pre-VAX.
>> 
>> Some dusty brain cells are thinking it may have been also used by some compilers
>> (or pre-processors) to separate statements on a single line. Which of course is
>> now done with semi-colons.
>> 
>> Walter
>> 
> 
> IMHO for some of these things on legacy code, judicious use of editors like sed
> should be used on the source codes and just bring them out of the dark ages.  It
> really is not that hard.  If the code is that important then just do it.
> Hacking compilers out of laziness just does not seem right.
> 
> I am not saying anyone is lazy and do not intend to offend, I fully understand
> what it is like to have over bearing workloads, but we should at least do a
> reality check.
> 
> Regards,
> 
> Jerry

Re: DEC Extension Support for gcc-4.8.3

[Jerry DeLisle]

On 03/08/2016 10:14 AM, Walter Spector wrote:
> Jerry DeLisle <jvdelisle@charter.net> wrote:
>> IMHO for some of these things on legacy code, judicious use of editors like sed
>> should be used on the source codes and just bring them out of the dark ages.  It
>> really is not that hard.  If the code is that important then just do it.
>> Hacking compilers out of laziness just does not seem right.
>>
>> I am not saying anyone is lazy and do not intend to offend, I fully understand
>> what it is like to have over bearing workloads, but we should at least do a
>> reality check.
> 
> That is MHO too.  A lot of simple stuff should just be fixed to be Standard conforming and be done with it.  In the case of VAX structures _without_ unions, it is pretty straightforward to simply use normal Fortran derived types.  Ones that do have unions need to be considered much more carefully.  Use of type extension and classes can solve some cases, but not all.

I have no issues at all with the structures and unions extensions.  The work is
done and as you say, unions can be a bit tricky.

> 
> Just remembered (and confirmed via some docs at bitsavers) that CDC Fortran used to use $ to separate multiple statements on a single line.  This of course was directly incompatible with IBM G and H Extendeds allowance of $ in variable names.
> 
Yes in this case depending on what the $ is used for, probably should be edited
out.  Its a case by case situation I am sure.

Jerry

Re: DEC Extension Support for gcc-4.8.3

[Walter Spector]

Jerry DeLisle <jvdelisle@charter.net> wrote:
>IMHO for some of these things on legacy code, judicious use of editors like sed
>should be used on the source codes and just bring them out of the dark ages.  It
>really is not that hard.  If the code is that important then just do it.
>Hacking compilers out of laziness just does not seem right.
>
>I am not saying anyone is lazy and do not intend to offend, I fully understand
>what it is like to have over bearing workloads, but we should at least do a
>reality check.

That is MHO too.  A lot of simple stuff should just be fixed to be Standard conforming and be done with it.  In the case of VAX structures _without_ unions, it is pretty straightforward to simply use normal Fortran derived types.  Ones that do have unions need to be considered much more carefully.  Use of type extension and classes can solve some cases, but not all.

Just remembered (and confirmed via some docs at bitsavers) that CDC Fortran used to use $ to separate multiple statements on a single line.  This of course was directly incompatible with IBM G and H Extendeds allowance of $ in variable names.

Walter

Re: DEC Extension Support for gcc-4.8.3

[Jerry DeLisle]

On 03/07/2016 04:10 PM, W Spector wrote:
> Tim Prince <n8tm at aol dot com> wrote:
>> ... I thought the purpose of permitting '$' was to support VMS system function
>> calls, so implicit integer may make sense. Such programs evidently won't be
>> portable even if you reconcile this bit.
> 
> Allowing $ in variable names was an old, old, ('60s/'70s) IBM mainframe
> extension, and maybe others of the era too.  I first encountered it in 1978 or
> so. So definitely pre-VAX.
> 
> Some dusty brain cells are thinking it may have been also used by some compilers
> (or pre-processors) to separate statements on a single line. Which of course is
> now done with semi-colons.
> 
> Walter
> 

IMHO for some of these things on legacy code, judicious use of editors like sed
should be used on the source codes and just bring them out of the dark ages.  It
really is not that hard.  If the code is that important then just do it.
Hacking compilers out of laziness just does not seem right.

I am not saying anyone is lazy and do not intend to offend, I fully understand
what it is like to have over bearing workloads, but we should at least do a
reality check.

Regards,

Jerry

Re: DEC Extension Support for gcc-4.8.3

[W Spector]

Tim Prince <n8tm at aol dot com> wrote:
> ... I thought the purpose of permitting '$' was to support VMS system function calls, so implicit integer may make sense. Such programs evidently won't be portable even if you reconcile this bit.

Allowing $ in variable names was an old, old, ('60s/'70s) IBM mainframe 
extension, and maybe others of the era too.  I first encountered it in 
1978 or so. So definitely pre-VAX.

Some dusty brain cells are thinking it may have been also used by some 
compilers (or pre-processors) to separate statements on a single line. 
Which of course is now done with semi-colons.

Walter