I just changed .f to .f90 and compiled with gfortran on my Mac (OSX 10.7) and found it fails compilation on the following line:
PartPos(1:3,1+nstart:nstart+npart(1))= pos(1:3, 1 + npart(0)):sum(npart(0:1)))
further up it is allocated and defined:
real*4,allocatable :: PartPos(:,:)
...
allocate(PartPos(1:3, 1:Ntot))
so it should run fine. The code compiles perfectly when I comment out the first line. My understanding is that the only difference between the two is the formatting (which could affect me). Could someone tell me what I'm missing. Sorry, I'm new to Fortran and have been searching for a solution for quite a while before I came here. Thanks in advance.
My (somewhat useless) error output:
PartPos(1:3,1+nstart:nstart+npart(1))= pos(1:3, 1 + npart(0)):sum(npart(0
1
Error: Unclassifiable statement at (1)
Compiled using:
>> gfortran program_test.f90 -o program_test
Your RHS appears to be missing a parenthesis [I see 4 "(" and 5 ")"].
Related
First of all, please read ---PS--- part. This problem is my misunderstanding.
I'm using ubuntu18.04 OS and intel fortran compiler of "parallel studio xe 2020 update 4" ifort.
I have tried to generate dependency among fortran source files using the ifort compiler with the -gen-dep option.
The following simple code was written for my test. The filename is "main.f90".
program main
use mod_a
implicit none
end program main
I executed following command to generate dependency of "main.f90".
ifort -gen-dep -syntax-only main.f90
As a result, I got following error message.
main.f90(2): エラー #7002: コンパイル済みモジュールファイルを開くときのエラーです。INCLUDE パスを確認してください。 [MOD_A]
use mod_a
--------^
The error message notifies that "mod_a.mod" file does not existed yet (while it is written in Japanese).
In the case the "mod_a.mod" has already been generated with compiling mod_a.f90, I got the following "true dependency" with executing above command.
main.o : \
main.f90 mod_a.mod
How can I generate dependency without generating mod_a.mod?
If it exist that the additional ifort options to achieve my goal, I want to know the options with priority.
Thank you for reading.
---PS---
I appologize to everyone who has read this post.
This problem is my misunderstanding.
I tried compiling my "main.f90" program again with ifort -gen-dep -syntax-only main.f90.
program main
use mod_a
implicit none
end program main
As a result, I got following error message and "true dependency".
main.f90(2): エラー #7002: コンパイル済みモジュールファイルを開くときのエラーです。INCLUDE パスを確認してください。 [MOD_A]
use mod_a
--------^
main.o : \
main.f90 mod_a.mod
I don't know why I didn't see this "true dependency", but my goal was already achieved.
However, additionally, I found a another probrem and solved it.
In the case that "main.f90" has huge code which use many subroutines, functions, variables, etc...
ifort -gen-dep -syntax-only main.f90 returned
fatal error: too many errors emitted, stopping now
and didn't return dependency.
To solve this problem, I added the -no-diag-error-limit to ifort command.
You need to supply information about mod_a.
Either compile it beforehand or supply it to the ifort -gen-dep command as such
$ ifort -gen-dep -syntax-only main.f90 mod_a.f90
main.o : \
main.f90 mod_a.mod
mod_a.mod : \
mod_a.f90
mod_a.o : \
mod_a.f90
When compiling cross-compiler tool crosstool-0.43 (for arm9) on the CentOS 7.5 64-bit system, I encountered the following error：
cc -c -o flat_bl.o /home/muhuo/arm-linux-project/transplant-test/build-tools/crosstool-0.43/build/arm-9tdmi-linux/gcc-4.1.0-glibc-2.3.2/binutils-2.16.1/gprof/flat_bl.m
/home/muhuo/arm-linux-project/transplant-test/build-tools/crosstool-0.43/build/arm-9tdmi-linux/gcc-4.1.0-glibc-2.3.2/binutils-2.16.1/gprof/flat_bl.m:2:2: error: expected identifier or ??before ??token
% the percentage of the total running time of the
^
I don't know what the *. m file in binutils-2.16.1 is. Whether I need to install some other tools before?
From the picture above, Compiling *.m file with GCC should be wrong.
I need some help. Thanks.
The problem is that there is a builtin '.m.o' suffix rule which triggers with a higher priority than the '.c.o' suffix rule. There was an attempt to disable this rule under PR2587 but because it is an old-style suffix rule this doesn't work.
There are two possible solutions, one is to remove all builtin rules by adding the line .MAKEFLAGS: -r to binutils/gprof/Makefile.in somewhere, or else more correctly change the .SUFFIXES: line in the same file so that the '.m' comes after '.c', thus changing the rule priority.
I'm having a hard time debugging a compilation error in gfortran. My compiler is:
gfortran -v
Thread model: posix
gcc version 4.9.2 (x86_64-posix-seh-rev4, Built by MinGW-W64 project)
I can't include the real problem because it's too big. Below I'll discuss a model problem of what's happening:
I have one big module, let's call it ops, that I'd like to break down into several modules (e.g. add, subtract, multiply, divide, etc). To do this, I "use" modules "add" and "subtract" in module "ops", make the routines from "add" and "subtract" public, and then call the routines in "add" and "subtract" from the main program, which only uses "ops".
In this simple example (illustrated below in a simple program), using both modules works fine, and there are no errors. But when I do this with my big program, I get an error when trying to use the "subtract" module (I've also included what I mean in the program comments).
Here's the sample of the scenario:
module add_mod
private
public :: add
interface add; module procedure add1; end interface
contains
subroutine add1(a,b,c)
integer,intent(inout) :: a
integer,intent(in) :: b,c
a = b + c
end subroutine
end module
module subtract_mod
private
public :: subtract
interface subtract; module procedure subtract1; end interface
contains
subroutine subtract1(a,b,c)
integer,intent(inout) :: a
integer,intent(in) :: b,c
a = b - c
end subroutine
end module
module ops
use add_mod
! use subtract_mod ! Removing comment causes error...
private
public :: init
public :: add
! public :: subtract ! Removing comment causes error...
contains
subroutine init(a,b,c)
implicit none
integer,intent(inout) :: a,b,c
a = 0; b = 0; c = 0
end subroutine
end module
program test
use ops
implicit none
integer :: a,b,c
b = 1; c = 1
call add(a,b,c)
write(*,*) 'a,b,c = ',a,b,c
! call subtract(a,b,c) ! want to call...
write(*,*) 'a,b,c = ',a,b,c
end program
The error that I'm getting (in terms of the simplified example) is:
\add.o
\subtract.o
\subs.o
\main.o
gfortran: error: main.o: No such file or directory
make: *** [main] Error 1
The error from my big example looks like
C:\\Users\\charl\\Documents\\obj\parametricStudy.o
gfortran: error: C:\\Users\\charl\\Documnts\\obj\parametricStudy.o: No such file or directory
make: *** [C:\\Users\\charl\\Documents\\MOONS] Error 1
Where "parametricStudy" is the main program and "MOONS" is the name of the target/executable.
This really does not look like an error in terms of finding the executable, it looks like the executable is not made because of some other issue, but I don't have enough information to find out why. I've tried including all of the debugging flags I can think of:
fimplicit-none -Wuninitialized -cpp -fopenmp -Wall -Wextra -fbacktrace -fcheck=all -O0 -Og
Sorry for the long introduction, but here's my question: How can I debug this? I'm sorry if this was a poorly conveyed question, but I can't re-produce this error in a simple case, so I'm not sure how else to pose the question. Any help on a solution, debugging advice or improving this question is greatly appreciated!
UPDATE:
After seeing the comment about the compilation error typo, I tried reversing the order of the used modules. That is, now I tried using "subtract" alone, which works fine, but then try using "add" (together) and I get the same error. I'm now beginning to think that this is a compiler bug or something.
UPDATE 2:
I uploaded the code to github. It can be downloaded at
https://github.com/charliekawczynski/MOONS
The makefile is in the directory
\MOONS\makefiles\MOONS
And the output should show up in out_dir. To compile this, the $TARGET_DIR$ and $SRC_DIR$ must be defined. Please note that right now it is defined with the variable $USER$.
After changing the directory, I see a different misspelling (which seems to change when I make small changes in the code, e.g. removing some warnings related to unused variables).
UPDATE 3:
I've been removing more warnings related to un-used routines and variables, and now I see that the error still exists, but (as far as I see) there is no typo. Here is the new output:
gfortran -o
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\MOONS -J"
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\mod" -fimplicit-none -Wuninitialized -cpp -D_DOUBLE_PRECISION_ -D_FFT_RADIX2_ -fopenmp -Wall -Wextra -fbacktrace -fcheck=all -O0 -Og -D_DEBUG_DEL_ -D_DEBUG_INTERP_ -D_DEBUG_APPLYBCS_
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\IO_tools.o
...
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\init_Ufield.o
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\init_Pfield.o
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\energySolver.o
...
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\MOONS.o
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\richardsonExtrapolation.o
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\convergenceRate.o
C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\parametricStudy.o
gfortran: error: C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\obj\init_Pfield.: No such file or directory
make: *** [C:\\Users\\charl\\Documents\\GitHub\\MOONS\\out_dir\\MOONS] Error 1
C:\Users\charl\Documents\GitHub\MOONS\makefiles\MOONS>
I'm going to try a newer compiler and see if this fixes the problem
I'm trying to get BLAS working with in a FORTRAN 77 program, but so far I've been unsuccesful and I can't figure out how to get going with this. For reference I'm doing this under Ubuntu 12.10.
This is the code of the program I'm trying to compile:
program blastest
implicit none
include 'cblas_f77.h'
end
The file cblas_f77.h resides in /usr/include, and there are both libblas.a and libblas.so (and a bunch of other BLAS related files) in /usr/lib.
How do you configure this to work properly?
So far, I've tried the following:
Note: adding -lblas to either of the options make no difference at all...
Just f77, no options (didn't really expect this to work, but what the heck...):
$ f77 blastest.f -o blastest
MAIN blastest:
Cannot open file cblas_f77.h
/usr/bin/f77: aborting compilation
f77 with include option to find the header file. Now, instead it fails on (despite the file name) not being coded with FORTRAN 77 in mind, so the first six columns are nonempty...
$ f77 blastest.f -o blastest -I/usr/include
MAIN blastest:
Error on line 1 of /usr/include/cblas_f77.h: nondigit in statement label field "/* "
Error on line 2 of /usr/include/cblas_f77.h: labeled continuation line (starts " * cbl")
Error on line 3 of /usr/include/cblas_f77.h: labeled continuation line (starts " * Wri")
...
Full output: http://pastebin.com/eZBzh9N5
Switched to gfortran, to be more flexible with the spacing in the header file:
$ gfortran blastest.f -o blastest -I/usr/include
Warning: cblas_f77.h:9: Illegal preprocessor directive
Warning: cblas_f77.h:10: Illegal preprocessor directive
Warning: cblas_f77.h:12: Illegal preprocessor directive
...
Full output: http://pastebin.com/P71Di9pR
OK, so I guessed I need -cpp to get the preprocessor working. That gave exactly the same output as above. Also, if you keep reading you see that the full output, the compiler is still complaining about labelled continuation lines further down...
I believe that you are using the C library "cblas". I would recompile with this command:
gfortran blastest.f -o blastest -L/usr/lib -lblas
and this should sort it all out. I do not believe (though i am not sure) that you need to make use of the "include" statement.
I've been tasked with maintaing some legacy fortran code, and I'm having trouble getting it to compile with gfortran. I've written a fair amount of Fortran 95, but this is my first experience with Fortran 77. This snippet of code is the problematic one:
CHARACTER*22 IFILE, OFILE
IFILE='TEST.IN'
OFILE='TEST.OUT'
OPEN(5,FILE=IFILE,STATUS='NEW')
OPEN(6,FILE=OFILE,STATUS='NEW')
common/pabcde/nfghi
When I compile with gfortran file.FOR, all lines starting with the common statement are errors (e.g. Error: Unexpected COMMON statement at (1) for each following line until it hits the 25 error limit). I compiled with -Wall -pedantic, but fixing the warnings did not fix this problem.
The crazy thing is that if I comment out all 4 lines starting with IF='TEST.IN', the program compiles and works as expected, but I must comment out all of them. Leaving any of them uncommented gives me the same errors starting with the common statement. If I comment out the common statement, I get the same errors, just starting on the following line.
I am on OS X Leopard (not Snow Leopard) using gfortran. I've used this very system with gfortran extensively to write Fortran 95 programs, so in theory the compiler itself is sane. What the hell is going on with this code?
Edit: Compiling with g77 gives:
test.FOR: In program `MAIN__':
test.FOR:154:
IFILE='TEST.IN'
1
test.FOR:158: (continued):
common/pabcde/nfghi
2
Statement at (2) invalid in context established by statement at (1)
Er, what context is established at (1)?
I don't think you can put COMMON statements below the executable statements in FORTRAN 77, see the specification, Sec. 3.5.
Just move the COMMON statement close to the beginning of the procedure, before any executable statement.