[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).
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.
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.
It's a simple question really, and refers to Linux (as opposed to Windows or Mac).
How do you generate a warning message from the C or C++ compiler that must have the word 'suspicious' in it, and must refer to (-Wmain).
(update)
Thanks Boann - I got some of those Warnings, but I also got Error - error: ‘::main’ must return ‘int’.
The reason I'm asking this question is that a week ago my compiler (GCC 4.8.1) came out with this warning saying 'suspicious' and that it was caused by Wmain. So I put -Wno-main and the warning went away and it compiled fine. Just recently it has started complaining making it an actual Error and not compiling. So I'm kind of worried that somehow the mother ship has covertly updated my compiler over the internet, without me knowing, and changed it to treat it as error. (I was probably using 'int4' as the return type which I forever have typedef'd as signed long int.
I note there's -Wmain referenced in g++ man page so it must be for something, but what warning is there that isn't overruled by an error??
At offset 557284 (decimal) of the g++ executable I found "Warn about suspicious declarations of "main".
For what it's worth,
struct suspicious {};
int main(suspicious) {}
Output with g++ -Wall, GCC 4.8.2:
warning: first argument of 'int main(suspicious)' should be 'int' [-Wmain]
If you refer to the -Wmain parameter of GCC, you get the warning by giving main odd arguments, an odd return type, or giving it static linkage. This will do it:
static float main(float x) {
return 0;
}
Compiled with gcc -Wmain, it displays these warnings; they do not actually contain the word 'suspicious' though:
warning: return type of 'main' is not 'int'
warning: first argument of 'main' should be 'int'
warning: 'main' takes only zero or two arguments
warning: 'main' is normally a non-static function
I just downloaded the sources for gcc 4.8.1 and searched all relevant files for the word "suspicious".
There are a number of occurrences, but as far as I can tell, there's no way an error message for a C or C++ source file can contain the word "suspicious". It's possible but unlikely that there was a local modification.
Is it possible that you're mistaken about what the error message said? If you have a log containing the error message, please update your question to show the exact message your received.
If you're concerned that your compiler may have been updated without your knowledge, you might check the timestamp of the compiler executable and of any programs it invokes (use gcc -v to check that). But gcc itself doesn't automatically update itself. If you're using it on a system administered by someone else, automatic updates are to be expected. If you administer the system yourself, you may have configured it to update software without manual intervention; if so, that's not a gcc issue. I don't know what "mother ship" you're referring to.
Surprisingly I found gcc can find this error when it compiles C. I simplified the code which still triggers the warning. I post the question for making clear the details of the techniques it uses. Below is my code of file a.c
int main(){
int a[1]={0};
return(a[1]);
}
My gcc version is gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3. When using gcc a.c -Wall, there is no warning; when using gcc -O1 a.c -Wall, there is a warning:
warning: ‘a[1]’ is used uninitialized in this function [-Wuninitialized]
and when using gcc -O2 a.c -Wall (or -O3), there is another warning:
warning: array subscript is above array bounds [-Warray-bounds]
The most surprising thing is that, when I give a[1] a value, then none of the above compiling options gives any warning. There is no warning even when I change the index to a huge number (of course the compiled file offends the operating system and will be kicked out),
int main(){
int a[1]={0};
a[2147483648]=0;
return(a[2147483648]);
}
I think the above phenomenon is more of a function than a bug. I hope someone help me figure out what happens, and/or why the compiler is designed so. Many thanks!
Accessing memory past the end of the array results in undefined behaviour.
gcc is nice enough to go out of its way to detect, and warn you about, some of these errors. However, it is under no obligation to do so, and certainly cannot be expected to catch all such errors.
The compiler is not required to provide diagnostic for this kind of error, but gcc is often able to help; notice that these warnings often arise in part as a byproduct of the static analysis passes done for optimization purposes, which means that, as you noticed, such warnings often depend from the specified optimization level.
I try to compile the fortran program which my advisor gave me.
It doesn't want to compile when I'm doing this with gfortran 4.7.2 on Mac OS X 10.8.4 and with gfortran 4.8.1 on Arch Linux x64.
I've built the minimal working example which replays the error. Unfortunately, it's quite big anyway, so I've put it on the github: https://github.com/kabanovdmitry/vode-test
I can compile this code under Ubuntu 12.04 with gfortran 4.6.3.
I've checked press releases for GCC 4.7 and found nothing that could give me a clue.
Could you please shed some light why gfortran doesn't want to compile this code?
Sorry, initially forgot to put the errors here:
main.f90:8.75:
call vode(istate, lambda_fcn, dummy_jac, lambda, x_tmp, x_end, tol, pm)
1
Error: There is no specific subroutine for the generic 'vode' at (1)
make: *** [all] Error 1
Your problem is covered by my answer and its comments in the question referenced by george. The type, kind and rank of arguments match exactly. To add something new, I suggest you to try to call the specific procedure directly. The type checker will then complaint for bad actual arguments and you will see more details.
In your case
generic2.f90:81.24:
call d_vode(istate, lambda_fcn, dummy_jac, lambda, x_tmp, x_end, tol, pm)
1
Error: Interface mismatch in dummy procedure 'f' at (1): Shape mismatch in dimension 1 of argument 'y'
Which is rather self-explaining. You dummy procedures are not compatible with your interfaces. You are mixing assumed-size and constant-size and explicit size arrays. You must follow the interface exactly.