I am trying to migrate a .FOR file (for practice purposes) from ifort to gfortran. This file compiles in my Intel Visual Fortran solution with no issues. However when I compile it in gfortran using the following command:
gfortran -ffree-form -ffree-line-length-200 -Dinternal_debug -c MyFile.FOR -o MyFile.o
I get the following error message:
MyFile.FOR:4561:22:
102 format(A, I)
1
Error: Nonnegative width required in format string at (1)
Does ifort simply not require there to be a format width or are there additional ifort options that enable relaxing this requirement? How come the file runs smoothly in ifort but not in gfortran?
Your observation is correct, I have encountered this myself before. Intel Fortran does not enforce this requirement while gfortran does. The field width is actually required by the Fortran standard. I am not aware of any compiler option that could change this behaviour. The only option I am aware of is to fix the code to make it standard compliant.
How to do it can be found in Error: Nonnegative width required in format string at (1) . Note that the g0 that you asked about is not a compiler option to accept I. It is a different format descriptor to put into the code instead of I.
Related
I am trying to compile a f77 file (dfsynthe.for) using gfortran.
Before that I tryed to compile it using ifort by ifort -double-size 64 -save -o dfsynthe.exe dfsynthe.for, and it worked.
However when I tried using gfortran by gfortran -std=legacy -fdec -w -o dfsynthe.exe dfsynthe.for I got a bunch or errors. I assume that there are some differences in the syntax when using gfortran and ifort, but I have no idea what exactly they are.
My ifort version is ifort (IFORT) 19.0.3.199 20190206 and gfortran version is GNU Fortran (Ubuntu 8.3.0-6ubuntu1~18.10.1) 8.3.0.
The errors I got from gfortran are mainly in five types:
dfsynthe.for:135:51:
OPEN(UNIT=15,STATUS='NEW',FORM='UNFORMATTED',
1
Error: Syntax error in OPEN statement at (1)
dfsynthe.for:434:20:
CLOSE(UNIT=12,DISP='DELETE')
1
Error: Syntax error in CLOSE statement at (1)
dfsynthe.for:475:11:
2 3046.604,2238.320,1713.711,1354.044,1096.776,
1
Error: Syntax error in DATA statement at (1)
dfsynthe.for:3225:29:
969 IF(T.GE.5000.)GO TO 979
1
Error: Label 979 referenced at (1) is never defined
dfsynthe.for:2327:48:
EQUIVALENCE (D(21),D5(1)),(D(26),D6(1)),(D(31),D7(1))
1
Error: Rank mismatch in array reference at (1) (1/2)
Here is the link for dfsynthe.for and the error log file error.log.
You may have the lines offset by 1 space or more. It appears you are trying to run old Fortran legacy code. Nothing wrong with that and it should run using Gfortran. Check your source code and confirm all statements start in column seven. If a line has a line number, as in 1000 continue be sure line number is in columns 2-6. If this still doesn't work or source code is formatted properly leave a note in the comments telling what you learned.
You might try renaming the file to dfsynthe.F77 and seeing how that works.
You have some tabs in the source file. Replace them with spaces and you will get a little farther.
Does anyone know if there is an option to suppress the following warning message
from gfortran:
Warning: Extension: Conversion from HOLLERITH to INTEGER(4) at (1)
(Without changing the code, that is).
I have already tried the options: -Wno-conversion-extra -Wno-conversion
I'm using gfortran 4.9.1 by the way.
Probably you can try this way:
-std=legacy
This may suppress the warning information as you mentioned since Hollerith constant is the legacy feature before FORTRAN77. However, downside of using this option is that all the possible legacy collision may not be shown. I have tested this option on gfortran 6.2.0.
This question already has an answer here:
Compiling issue with ifort composer_xe_2015.3.187
(1 answer)
Closed 7 years ago.
I am using a numerical model that is sensitive to the precision of numerics. With my old ifort compiler I successfully used the Fortran flags
"fp-model precise"
I recently installed intel compiler composer_xe_2015.3.187. It does not recognize the Fortran flag
"fp-model precise".
This is the exact error that I get
f95: error: precise: No such file or directory
f95: error: unrecognized command line option ‘-fp-model’
I am afraid if I would be sacrificing my efficiency in lieu of the new compiler or is the new one inherently able to maintain precision.
The compiler you are invoking with the name f95 is not Intel Fortran. Based on the error message, I'm guessing it is actually the GNU Fortran compiler, but you can check for sure by running f95 -v to see what the compiler identifies itself as.
Intel Fortran 15 still supports the option -fp-model precise.
Before invoking ifort, you need to setup its environment, e.g.
source /path/to/intel/bin/ifortvars.sh intel64
for the 64 bit compiler. You can then invoke the compiler as ifort.
[NOTE: contains repetition of previous question but posted separately as separate issues]
I am compiling a program which is known to compile with ifort using gfortran. However the compiler fails on the line
IF (IANG.NE.0) IANG=IANG*SIGN(1.0,XX(4))
with the compile error:
make: *** [main_file.o] Error 1
Changing this line to (note D0)
IF (IANG.NE.0) IANG=IANG*SIGN(1.0D0,XX(4))
solves the problem
The compiler flags are:
gfortran -fno-automatic -mcmodel=medium -O2 -ffast-math main_file.o -o main_file
Even an explanation for this behaviour would be appreciated.
Cheers,
Derek
The cause of the compilation error is likely to be a mismatch between the type+kind of 1.0 and XX(4), the Fortran standard requires that the arguments to SIGN match in both kind and type. Since you haven't shown us the declaration of the array XX I feel confident in asserting that it is probably declared to be real with kind=kind(1.0d0).
I am trying to compile some Fortran code that, according to the documentation, is known to compile with "Intel Fortran Compiler 11." However, when I try to compile the code using the version of ifort that comes with Intel® Fortran Composer XE 2013 for OS X (here: http://software.intel.com/en-us/fortran-compilers), I get a number of errors. I suspect that I'm either 1) using a compiler that's incompatible with the exact dialect of Fortran used and/or 2) failing to include some necessary libraries.
I'm not a Fortran programmer, so I'm hoping that someone with more experience will be able to glance at the code and recognize if it's just a simple matter of using a different compiler, setting some compiler options, including some specific libraries, or if I'm missing something else altogether.
The full source code can be found just above the Contents here: http://baydeltaoffice.water.ca.gov/modeling/deltamodeling/models/dsm2/dsm2.cfm
To start with, I'm just trying to compile groups.f in /DSM2_v8_0_6_src/dsm2_v8_0/src/common (which requires that a few other modules be compiled first), but the eventual goal is to compile DSM2_v8_0_6_src/dsm2_v8_0/src/ptm/native/fixedData.f and all of its dependencies.
The syntax I'm using follows this basic pattern:
ifort -c DSM2_v8_0_6_src/dsm2_v8_0/src/common/groups.f
To get a sense of the types of errors I'm encountering, here are a couple of types that occur repeatedly:
groups.f(225): error #5082: Syntax error, found END-OF-STATEMENT when expecting one of:
( * ) :: , . % + - [ : . ** / // .LT. < .LE. <= .EQ. == ...
write(unit_error,*)"Error in matching text pattern:",trim(pattern)
---------------------------------------------------------------------^
groups.f(265): error #5120: Unterminated character constant
& "Error in pattern matching. Implementation count does not equal count in NumberMatches"
------^
Could be F77 or F90 depending on how you have done the formatting. Stack oveflow fomatting requires 4 spaces to start the code. On the line 225, is it indented by 6 or not indented at all. If it is indented by 6 and line 265 is indented by 5 then it is F77.
The other question is whether leading spaces have been stripped when moving from one machine to another. If that is the case then they need to be re-inserted.
On the first line with an error, check the line terminations. All lines should end with either CR LF or just LF. If there is a mix, the compiler will throw a wobbly.
If it is F77, try renaming the files with a .f extension to a .for extension. ifort will then definitely pick them up as f77.
In case this might help point somebody with a similar problem in the right direction, after doing some digging I was able to determine that the code was originally compiled using Visual Studio with the compiler option FixedFormLineLength="fixedLength132". So, using ifort from the command line, I can compile using the following basic pattern (omitting all of the include paths, etc., for clarity):
ifort -c -132 DSM2_v8_0_6_src/dsm2_v8_0/src/common/groups.f
As for the dialect, I later heard from the provider that the code was mostly written in Fortran 77, with some parts later revised to Fortran 90.