Hello,I compiled the program without -fdec and -ffixed-form and got this error:
Currently, my attention is on Legacy code, DEC/VMS.
IMOH, the results I see seem to be confusing. Maybe
it's my fault or GNU Fortran after version 8 gives
different results or what else?.
Results from other compilers that support DEC/VMS
extensions will be appreciated!
Thanks,
Ev. Drikos
--------------------------------------------------
$ gfc -ffixed-form par.f && ./a.out
parameters= 2.00000000
$ gfc -ffree-form par.f && ./a.out
parameters= 2.00000000
$ gfc --version 2>&1 | head -n1
GNU Fortran (GCC) 4.8.5
$ gfortran8 -fdec -ffixed-form par.f && ./a.out
parameters= 2.80259693E-45
$ gfortran8 -fdec -ffree-form par.f && ./a.out
parameters= 2.80259693E-45
$ gfortran8 --version 2>&1 | head -n1
GNU Fortran (GCC) 8.4.0
$ cat par.f
parameters = 2.0
print *, 'parameters=', parameters
end
Hello,
Currently, my attention is on Legacy code, DEC/VMS.
IMOH, the results I see seem to be confusing. Maybe
it's my fault or GNU Fortran after version 8 gives
different results or what else?.
Results from other compilers that support DEC/VMS
extensions will be appreciated!
Thanks,
Ev. Drikos
--------------------------------------------------
$ gfc -ffixed-form par.f && ./a.out
parameters= 2.00000000
$ gfc -ffree-form par.f && ./a.out
parameters= 2.00000000
$ gfc --version 2>&1 | head -n1
GNU Fortran (GCC) 4.8.5
$ gfortran8 -fdec -ffixed-form par.f && ./a.out
parameters= 2.80259693E-45
$ gfortran8 -fdec -ffree-form par.f && ./a.out
parameters= 2.80259693E-45
$ gfortran8 --version 2>&1 | head -n1
GNU Fortran (GCC) 8.4.0
$ cat par.f
parameters = 2.0
print *, 'parameters=', parameters
end
real :: parametersx=10
I sort of "like" this bug
Hello,
Currently, my attention is on Legacy code, DEC/VMS.
IMOH, the results I see seem to be confusing. Maybe
it's my fault or GNU Fortran after version 8 gives
different results or what else?.
Results from other compilers that support DEC/VMS
extensions will be appreciated!
Thanks,
Ev. Drikos
--------------------------------------------------
$ gfc -ffixed-form par.f && ./a.out
parameters= 2.00000000
$ gfc -ffree-form par.f && ./a.out
parameters= 2.00000000
$ gfc --version 2>&1 | head -n1
GNU Fortran (GCC) 4.8.5
$ gfortran8 -fdec -ffixed-form par.f && ./a.out
parameters= 2.80259693E-45
$ gfortran8 -fdec -ffree-form par.f && ./a.out
parameters= 2.80259693E-45
$ gfortran8 --version 2>&1 | head -n1
GNU Fortran (GCC) 8.4.0
$ cat par.f
parameters = 2.0
print *, 'parameters=', parameters
end
real :: parametersx=10
parameters = 2.0
print *, 's=', s
print *, 'parameters=', parameters
end
I sort of "like" this bug
For something that short to be so surprising is interesting; some compilers even have problems with the above ...
On 5/6/2022 11:52 AM, Ron Shepard wrote:
$ cat par.f
parameters = 2.0
print *, 'parameters=', parameters
end
Since this is ambiguous syntax, I do not know how other f77 compilers
with VAX extensions would treat this code. I don't even know what a VAX
fortran compiler would do with those extensions enabled. If those
extensions are not enabled, then both lines should trigger compiler
warnings about the long variable name PARAMETERS.
The no-parenthesis PARAMETER syntax was part of the FORTRAN-77 draft
right up until the published standard. DEC went ahead and implemented
it, assuming it would be part of the final standard. When it wasn't,
they had to support both. It is really more a lesson in the danger of fixed-form.
$ cat par.f
parameters = 2.0
print *, 'parameters=', parameters
end
Since this is ambiguous syntax, I do not know how other f77 compilers
with VAX extensions would treat this code. I don't even know what a VAX fortran compiler would do with those extensions enabled. If those
extensions are not enabled, then both lines should trigger compiler
warnings about the long variable name PARAMETERS.
Steve Lionel <steve@seesignature.invalid> schrieb:
On 5/6/2022 11:52 AM, Ron Shepard wrote:
$ cat par.f
parameters = 2.0
print *, 'parameters=', parameters
end
Since this is ambiguous syntax, I do not know how other f77 compilers
with VAX extensions would treat this code. I don't even know what a VAX
fortran compiler would do with those extensions enabled. If those
extensions are not enabled, then both lines should trigger compiler
warnings about the long variable name PARAMETERS.
The no-parenthesis PARAMETER syntax was part of the FORTRAN-77 draft
right up until the published standard. DEC went ahead and implemented
it, assuming it would be part of the final standard. When it wasn't,
they had to support both. It is really more a lesson in the danger of
fixed-form.
... and of not using IMPLICIT NONE, of course.
Free form still has two important advantages: It is possible to use
British English spelling, as in
PROGRAMME MAIN
and it is possible to group numbers, as in
N = 123 234 567
On 5/7/22 9:42 AM, Thomas Koenig wrote:
Steve Lionel <steve@seesignature.invalid> schrieb:
On 5/6/2022 11:52 AM, Ron Shepard wrote:
$ cat par.f
parameters = 2.0
print *, 'parameters=', parameters
end
Since this is ambiguous syntax, I do not know how other f77 compilers
with VAX extensions would treat this code. I don't even know what a VAX >>>> fortran compiler would do with those extensions enabled. If those
extensions are not enabled, then both lines should trigger compiler
warnings about the long variable name PARAMETERS.
The no-parenthesis PARAMETER syntax was part of the FORTRAN-77 draft
right up until the published standard. DEC went ahead and implemented
it, assuming it would be part of the final standard. When it wasn't,
they had to support both. It is really more a lesson in the danger of
fixed-form.
... and of not using IMPLICIT NONE, of course.
This has been mentioned a couple of times now in this thread, and just
as a reminder IMPLICIT NONE was not part of standard fortran until f90.
So if one wanted to write standard code in the 1980s, this was not an
option.
On the other hand, as I've stated before, if you wanted to do something useful and nontrivial, or if you were concerned about portability of the code, you were almost required to use extensions to the language. F77 by itself was just missing too much functionality. Vendors at that time
were happy with that situation because it allowed them to lock in their customers who relied on their extensions. IMPLICIT NONE was one of those useful extensions -- portable but nonstandard in that case.
$.02 -Ron Shepard
... and of not using IMPLICIT NONE, of course.
This has been mentioned a couple of times now in this thread, and just
as a reminder IMPLICIT NONE was not part of standard fortran until f90.
So if one wanted to write standard code in the 1980s, this was not an
option.
I used to use
IMPLICT CHARACTER*1 (A-Z)
which caught many, if not all, errors. Inventing a variable name
in a subroutine argument was not caught this way, for example.
"Thomas Koenig" wrote in message news:t56tfm$u2s$1@newsreader4.netcologne.de...
I used to use
IMPLICT CHARACTER*1 (A-Z)
which caught many, if not all, errors. Inventing a variable name
in a subroutine argument was not caught this way, for example.
Wouldn't
IMPLICIT CHARACTER*(*) (A-Z)
have caught a couple more errors?
.. a reminder IMPLICIT NONE was not part of standard fortran until f90.
So if one wanted to write standard code in the 1980s, this was not an
option ..
James Van Buskirk <not_valid@comcast.net> schrieb:
"Thomas Koenig" wrote in message
news:t56tfm$u2s$1@newsreader4.netcologne.de...
I used to use
IMPLICT CHARACTER*1 (A-Z)
which caught many, if not all, errors. Inventing a variable name
in a subroutine argument was not caught this way, for example.
Wouldn't
IMPLICIT CHARACTER*(*) (A-Z)
have caught a couple more errors?
Possibly, but the people who wrote up the advice at the time
didn't think of it, and neither did I :-)
After I moved my development to UNIX-based Fortran compilers which
supported IMPLICIT NONE, the point became moot. f2c also supports
this, IIRC.
On Saturday, May 7, 2022 at 12:21:39 PM UTC-4, Ron Shepard wrote:
.. a reminder IMPLICIT NONE was not part of standard fortran until f90.
So if one wanted to write standard code in the 1980s, this was not an
option ..
And that remains yet another unfortunate event in the history of Fortran.
ANSI X3.9-1978 document toward FORTRAN 77 was approved by ANSI on April 3, 1978 that became the de facto standard reference for FORTRAN 77.
Now consider MILITARY STANDARD 1753 FORTRAN, US DoD Supplement To American National Standard X3.9-1978 dated November 9, 1978, months later:
https://wg5-fortran.org/ARCHIVE/mil_std_1753.html
which introduced `IMPLICIT NONE` that was recognized as useful by many users at the time and which was then implemented by many compilers as an extension that became popular enough to make it into Fortran 90 revision, 13 years later.
If only `IMPLICIT NONE` had made into ANSI X3.9-1978 document itself, clearly the notion of `IMPLICIT NONE` must have been circulating given its appearance just months later in the MIL-STD 1753 document!
And if only Fortran 90 had instead made `IMPLICIT NONE` the default (the semantics of explicit everything), at least for all the new program scopes it introduced such as INTERFACEs and MODULEs! That is, as compromise at least given all the crazybattles that supposedly characterized Fortran standard revision during the 1980s :-(
That was some serious failure of imagination back then which handicapped the practice of Fortran.
This has been mentioned a couple of times now in this thread, and just
as a reminder IMPLICIT NONE was not part of standard fortran until f90.
So if one wanted to write standard code in the 1980s, this was not an
option.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 157 |
Nodes: | 16 (0 / 16) |
Uptime: | 16:19:03 |
Calls: | 3,193 |
Files: | 10,512 |
Messages: | 2,978,769 |