Of course. But it also duplicated the existing facility of using DATA initialization - which also adds the SAVE attribute.
Interesting use. But it complicated the use of a function. I wasn’t aware it before.
Should invent something like:
save none
To correct this.
Just like ‘implicit none’ to avoid error.
Flang has implemented a warning for this, take the following example:
PROGRAM test
USE ISO_FORTRAN_ENV
IMPLICIT NONE
REAL(real64) :: pi
pi = 3.14159265358979323846
WRITE(*, '(A, A)') "String literal: ", "3.14159265358979323846"
WRITE(*, '(A, F24.20)') "The value of pi is: ", pi
END PROGRAM test
Compile with default flags and run:
$ flang cast-warning.F90
./cast-warning.F90:5:10: warning: Default real literal in REAL(8) context might need a kind suffix, as its rounded value 3.1415927410125732421875_4 is inexact [-Wreal-constant-widening]
pi = 3.14159265358979323846
^^^^^^^^^^^^^^^^^^^^^^
$ ./a.out
String literal: 3.14159265358979323846
The value of pi is: 3.14159274101257324219
And there are no warnings for those values which cast to double prec. without any rounding error. Replace pi with `2.0` in the example above and the warning goes away.
The last time I used the Oracle/Sun Developer Studio compiler (probably about 8 years ago), it appeared to default to static allocation of local variables. I had some old code that didn’t work correctly with ifort, gfortran etc. but did with the Oracle/Sun compiler. When I got to looking deeper into the code, I realized it was assuming a local index variable was stored (statically) after the first call. As you state this was common Way Back When but its not the behaviour folks reared on more modern processors and Fortran versions expect.
Also, It appears Oracle stopped development of their Developer Studio compilers around 2017. At least that is the last version publically available. Anyone know if they are still doing anything with compiler development but only releasing it to their paying customers.
It’s more likely to be an extension to the IMPLICIT statement, if it is ever agreed on.
implicit none (save)
to go along with
implicit none (type)
implicit none (external)
There is already a save statement which accepts a list of variable names. I don’t see how it has any connection to implicit.
The warning is suppressed with the change:
pi = real(3.14159265358979323846,kind(pi))
If the programmer intends for the literal constant to be default real and not real64, then this is probably a good way to write the code anyway. Otherwise, I think these type/kind conversion warnings are a good idea for the reasons mentioned before.
This statement already has a meaning, namely that the variable none has the save attribute. Extending the implicit declaration to cover this case seems like a good idea. This would essentially elevate the optional warning that some compilers give in these cases to an error, which is what I think should have been done starting at f90.
Yes, the DATA statement was extended (in f2003 I think) to also include implicit save. In f77, where the save statement was introduced, the data statement did not imply save. Without save, the semantics was only defined when the data item was unmodified. Otherwise, the value was undefined upon return after any change or redefinition, and it was the programmer’s responsibility to ensure that it was defined again at some later time before being referenced.
I would also say that initialization on the declaration statement and in a data statement do have some overlap, but there are also some important differences. For example, expressions can be used in the declaration statement, but not in a data statement. Subsets of arrays can be initialized in a data statement, but not in a declaration statement. Repeat count syntax can be used in data statements, but not declaration statements. So there are still some practical uses for data statements even now. Here is a simple example.
PROGRAM fibonacci
implicit none
integer, parameter :: n = 20
integer :: i, fib(n)
data fib(1:2) / 2*1 /
do i = 3, n
fib(i) = fib(i-2) + fib(i-1)
enddo
print '(*(i0:1x))', fib
END PROGRAM fibonacci
$ flang xxx.f90 && a.out
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987 1597 2584 4181 6765
I think that is standard, although maybe an implied do loop should be used in the data statement (ala f77) instead of an array slice (ala f90). This is a main program, so the save status is irrelevant, but I think the data statement triggers the implicit save attribute for the whole array fib(:).
We are discussing the lack of syntax to express to the compiler that it should only consider objects to have the SAVE attribute if and only if there is a SAVE in the attribute list in the declaration of the object, or there is a SAVE statement for that object. We want it to reject Integer :: i=1 but accept Integer, Save :: i=1. The missing syntax is a natural fit for the IMPLICIT statement.
Beautiful! I independently discovered this yesterday and was pleased with the warning. The warning message could be improved, I know what it’s trying to say, but I have a hard time understanding it as written. But that can be done easily, important is to warn.
This is off topic so maybe we should start a new thread if we continue this sidebar. I’ll just comment that (afaik) implicit only pertains to type and kind, and no other attributes. I mentally map save (and its missing opposite) similarly to public/private/protected ::, and import, all/none/only :. So something like save, all/none/only : seems more natural to me than increasing the scope of implicit.
lFortran doesn’t support C comment line.
It does, you need to enable fixed-form by --fixed-form.
With –fixed-form only, no warning on c comment line, but warning on any other first line:
Tokenizer error: ICE cannot recognize global scope entity.
In the example, need to add a line with: integer a
My extension name is .f90. Same error for .f
If I change to .for, there is linking error on my phone.
I see, I can reproduce it using your cline.f90 code, I reported it at Support fixed-form code without a program line · Issue #11057 · lfortran/lfortran · GitHub. Thanks!
It’s fixed in the latest main.
Thanks. I need to figure out how to build Lfortran by myself now.
First on Window 10. I have msvc 2022. The cl /? and link /? all print help in msvc’s terminal.
Downloaded the src from github as a zip file. When unzip, one error msg:
Cannot create symbolic link : A required privilege is not held by the client. : D:\00masterLib\lfortran-main\CLAUDE.md
We’ll make a new release soon, so you can just grab the conda package. Building from source, especially on Windows is not as easy, but if you want to do it, we have documentation here: Installation — LFortran.
That’s great. Are you building with ‘-DWITH_RUNTIME_STACKTRACE=yes’?
I tried to use cmake with lfortran, It gives me this semantic error which need it set at YES.
Here are the error messages and demo project. Only one f90 file and a CMakeLists.txt file. In the build folder run ‘cmake ..’ to build. Please remove .txt from lf.zip.txt and then unzip
lf.zip.txt (752 Bytes)
I am using your CMakeLists.txt to build lfortran under Windows 10.
On line 16 of your CMakeLists.txt:
file(STRINGS "${CMAKE_CURRENT_SOURCE_DIR}/version" LFORTRAN_VERSION)
string(REGEX MATCH "^[^-]*" LFORTRAN_NO_TAG_VERSION ${LFORTRAN_VERSION})
There is no ${CMAKE_CURRENT_SOURCE_DIR}/version file, so it’s not right here. You need to provide one ‘version’ file or remove this part about LFORTRAN_VERSION.
Per the installation instructions (Installation — LFortran), you need to run build0.bat which creates it.
The cmake integration had some issues on Windows, that might be a bug in cmake.
Not sure — try building without it first.