I am trying to compile a fortran file along with some .h files in FORTRAN. The .h files contain definition for common blocks of variable. When I compile them in Fortran, I get the following error:
integer knue,ke,knumu,kmu,knutau,ktau,ku,kd,kc,ks,kt,kb,kgamma,
1
Error: Invalid character in name at (1)
The code where this error occurs is,
Now my question is, does this "1" point where the error is?
The lines of code which this errors points is,
integer knue,ke,knumu,kmu,knutau,ktau,ku,kd,kc,ks,kt,kb,kgamma,
& kw,kz,kgluon,kh1,kh2,kh3,khc,ksnue,kse1,kse2,ksnumu,ksmu1,
& ksmu2,ksnutau,kstau1,kstau2,ksu1,ksu2,ksd1,ksd2,ksc1,ksc2,
& kss1,kss2,kst1,kst2,ksb1,ksb2,kn1,kn2,kn3,kn4,kcha1,kcha2,
& kgluin,kgold0,kgoldc
Also, is there something wrong with the way continuation are used. I am using gfortran to compile this file.
It looks like you are using Fortran 77 style line continuations and trying to compile with Fortran 90 style free format code. You either need to compile using the gfortran -ffixed-form option, or format the code using Fortran 90 style line continuations:
integer knue,ke,knumu,kmu,knutau,ktau,ku,kd,kc,ks,kt,kb,kgamma, &
kw,kz,kgluon,kh1,kh2,kh3,khc,ksnue,kse1,kse2,ksnumu,ksmu1, &
ksmu2,ksnutau,kstau1,kstau2,ksu1,ksu2,ksd1,ksd2,ksc1,ksc2, &
kss1,kss2,kst1,kst2,ksb1,ksb2,kn1,kn2,kn3,kn4,kcha1,kcha2, &
kgluin,kgold0,kgoldc
I had this problem when modifying scipy and trying to compile it. The following identation was necessary to make it work, with the star * at column 5. It works for both Fortran 77 and 90 styles.
double precision a,abseps,abserr,alist,area,area1,area12,area2,
* a1,a2,b,blist,b1,b2,correc,dabs,defabs,defab1,defab2,d1mach,
* dmax1,dres,elist,epmach,epsabs,epsrel,erlarg,erlast,errbnd,
* errmax,error1,error2,erro12,errsum,ertest,f,oflow,resabs,
* reseps,result,res3la,rlist,rlist2,small,uflow,areav
To your first question, yes the "1" normally denotes the point in the code where the error occurs. The code as such looks ok otherwise.
Actually the Fortran 77 continuation column is number six.
http://web.stanford.edu/class/me200c/tutorial_77/03_basics.html
Related
I am testing code-generation functionality and deliberately creating very large .go source files.
However I see errors with go compiler at line 1048575 (which is 0xFFFFF) such as:
generated.go:1048575:75: invalid character U+0040 '#'
generated.go:1048575:76: const declaration cannot have type without expression
generated.go:1048575:88: syntax error: unexpected E_Blah_Blah, expecting semicolon or newline or )
Is this a known limitation?
EDIT-1: Commenters asked for more info on content of generated file; further tests show when I deliberately introduce a new error at line 1048573 or 1048574 it gets reported as I'd expect, but if I introduced one at 1048575 or higher line number the file I always get the error reported at 1048575.
EDIT-2: I realise now the original issue invalid character U+0040 '#' was indeed a bug in my generated file but it was further down that line number the compiler tells me.
EDIT-3: So I guess the question should really have been:
is there a way to have the go-compiler give the correct line number for a problem if error further down than line 0xFFFFF?
Is this a known limitation ?
No.
The root cause was:
https://github.com/golang/go/issues/36850
i.e. Compiler bug: error line number is capped at 0xFFFFF
as per comment from #icza
I'm trying to install libssh-0.8.5 onto Ubuntu 16.04 using the instructions from the install.readme provided. I follow every step as stated, but I get an error after executing the make command to build the project. The error is as follows:
[ 65%] Built target exec
tests/CMakeFiles/ssh_ping.dir/flags.make:8: *** target pattern contains no '%'. Stop.
CMakeFiles/Makefile2:1696: recipe for target 'tests/CMakeFiles/ssh_ping.dir/all' failed
make[1 ]: *** [tests/CMakeFiles/ssh_ping.dir/all] Error 2
Makefile:160: recipe for target 'all' failed
make: *** [all] Error 2
I have researched and seen that it could be a syntax error somewhere in my make file that is preventing the build to continue. I have looked at the target make file giving the problem, but cant seem to identify what is causing the error.
The flag.make file is as follows:
The problem seems to be coming from the highlighted bold line. Can anyone see what I am missing?
On StackOverflow (and most other similar sites), please cut and paste text into your questions and format them using the proper markdown facilities, rather than attaching images containing text. The latter is difficult to read and we can't cut and paste it into our answer to show where things are going wrong.
You cannot embed newlines in quoted strings, in makefiles. Make is completely line-oriented and does not parse quotes at all. So to make this:
FOO = "bar
biz"
is not considered one line assigning a value containing a newline to a variable FOO. Instead, it's considered two lines, the first of which is assigning the value "bar to variable FOO and the second of which is a syntax error since make can't parse the string baz" as a valid command.
Apparently ssh wasn't installed properly on your platform, while cmake relies on it. I am a bit surprised that cmake itself did not raise an error when generating flag.make but as I don't use cmake I do not know whether it is its normal behaviour or not.
Anyway, when cmake tried to detect your version of OpenSSH it did it by running ssh and got an error message instead of the version number it wanted. This error message got inserted in the generated flag.make Makefile. Because the second line of this error message (I could copy-paste it here if it was not in a picture in your question) has the:
a: b: c
form, make tried to interpret it as a static pattern rule but as it contains no % wildcard character, make raised a syntax error.
What happens if you try to run /usr/bin/ssh -V on the command line?
As a part of a larger program, written in the new Fortran standard, I am interested to write some text on a file that will be read by another program over which I have no control.
Long ago when I learned Fortran an output record generated by a format statement should begin with an LF (linefeed) and end with a CR (carriage return). This means that each output record should be separated by a sequence CRLF.
To my surprise I find that this seems no longer to be true except when I compile and run my program on a Windows computer. When I compile and run my program on a Mac the output records are separated by a single LF. I know this is a Linux standard but I guess I assumed the output from a Fortran program should not depend on the operating system.
The consequence of this is that when I generate the output on Windows my output file can be read by the other program (which only exists on Windows) whereas when I generate the same output on my Mac it fails.
I have no idea how the other program reads the file but I assume it is a standard Fortran read.
I have also compared my output file from Windows and Mac using "diff" and that indicates all lines are different. However "diff -w" indicates the files are identical.
I would like to be able to generate output that can be read by the other program independently if I generate the file on a Mac or Windows. I know I can use things like #ifdef to check the OS when I compile but I wonder if there is any other way, are there some option in the Fortran write? I know there are a lot of new things line "noadvance" etc. Any option to force a "CRLF" record separator?
I use GNU Fortran version 5.2 on Windows and what seems to be called version 7.2 on the Mac
According to the documentation, gfortran allows a peculiar flag for the OPEN statement, called CARRIAGECONTROL, as in:
program prg
integer :: u
open (newunit = u, file = 'test.txt', carriagecontrol = 'fortran')
write (u, '(A,I2)') '-', 12
write (u, '(A,I2)') '-', 34
close (u)
end program prg
This option is only supported when the code is compiled with the -fdec switch. The content of the output file is then:
> hexdump -C test.txt
00000000 0a 31 32 0d 0a 33 34 0d |.12..34.|
00000008
which is exactly the format that you described. The minus signs in the I/O lists in the above code are consumed by the compiler runtime library and used to redefine the output format. (Tested with gfortran 9.2.)
I am trying to compile a fortran code. It will analyze an X file in an Y directory and then create a new file Z with the results. But there is something wrong occurring.
When I write the directory I see that it is too much for one line and then I try to continue it in the next one doing this:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'
+ 'espec.fits'
But, when I try to compile using the command
gfortran Codigo.f -o TESTE -Lcfitsio -lcfitsio
I get this error message:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
Can someone help me? Actually I do not know what this error is. The directory is 100% right. And when I move the archives to a simpler directory to be able to write everything in one line, it works! So is there something wrong with the "+"?
Thank you.
Edit1
Actually, when I add "&" in the end of the line, it gives me this error message:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'&
1
Error: Unclassifiable statement at (1)
Codigo.f:60.7:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
And with "//":
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/'//
1
Error: Syntax error in expression at (1)
Codigo.f:60.7:
+ 'espec.fits'
1
Error: Invalid character in name at (1)
Edit2
Thank you so much for helping me. Well, I solved the problem switching to the ".f90" form.
Just one more question: do you know why it does not recognize the "c" for comments in the code? Thank you again! :)
This part of your compilation statement:
gfortran Codigo.f
will treat the source file, with its .f suffix, as fixed form source. This means that a continuation line is indicated by any character (other than a blank or a 0) in column 6.
However, the error message you get suggests that the + in the second line of your snippet is not in column 6 and that the compiler is treating it as the initial character in a new entity name for which it is not valid. The fact that the + is aligned, vertically, with n in the previous line strengthens my suspicion that this may the root of your problem.
Adding the ampersand, as suggested in a now-deleted answer, doesn't actually help in this case if you continue to tell the compiler that it is dealing with a fixed form source file. & is only used for continuation in free form source files. Adding the string-concatenation operator, //, doesn't help either since it is not followed by another string but a line ending. //& would help but is probably unnecessary.
I think you have 2 possible solutions, but choose only one:
Stick with fixed form and get the alignment right.
Change the file suffix to .f90 which will cause gfortran to treat the source file as free-form.
If you go for option 2 (which I would recommend) you can then either use & at the end of the continued line or you could simply merge the lines. In free-form the maximum line length is 132 characters.
Adding to High Performance Mark's answer:
If you continue with FORTRAN 77, most compilers have an option to increase the allowed line length, e.g., -ffixed-form -ffixed-line-length-none for gfortran. As already stated, Fortran >=90 has line length of 132, so you wouldn't need to split the line.
Finally, if you want to split the line in Fortran >=90, you need two ampersands. In most cases you need one, but to split a string you need two:
namech='/home/matheus/Documents/UFABC/IC/Spectra/Elliptical/&
&espec.fits'
I am trying to get this Ruby inline C code http://pastie.org/2825882 to work. The code works in vanilla C, but here I get errors and warnings. What causes this error?
./backtrack_inline.rb:67: error: lvalue required as unary '&' operand
Also, why do I get the following error?
./backtrack_inline.rb:73: error: too few arguments to function 'backtrack'
Inspecting the resulting C code ( http://pastie.org/2826036) I fail to see anything wrong with the arguments. But I do also get the following warnings:
./backtrack_inline.rb:73: warning: passing argument 1 of 'backtrack' makes integer from pointer without a cast
./backtrack_inline.rb:73: warning: passing argument 2 of 'backtrack' makes integer from pointer without a cast
./backtrack_inline.rb:73: warning: passing argument 3 of 'backtrack' makes integer from pointer without a cast
Starting with this:
./backtrack_inline.rb:73: error: too few arguments to function 'backtrack'
If you look at your generated code, the backtrack function is defined on line 29:
static VALUE backtrack(VALUE self, VALUE _ss, VALUE _s, VALUE _p, VALUE _mm, VALUE _ins, VALUE _del) { ... }
It has seven arguments, the original six, plus VALUE self as it has been converted into a method on the Scan class.
The call to this function, on line 67 looks like this:
end = backtrack(ss, s, p, mm, ins, del);
It has only six arguments. RubyInline doesn't convert this to a call to a method on the object, it simply copies it verbatim. This is also where the warnings about makes integer from pointer without a cast come from: the function definition has been converted to take VALUEs, but you're calling with the original types.
The error message says that the error is from line 73 in backtrack_inline.rb because of the directive on line 54 of the generated code:
# line 61 "./backtrack_inline.rb"
which basically tells the compiler to "reset" its line and file values for errors, and treat the next line (55) as being line 61 in the file ./backtrack_inline.rb. The actual line is 67, 12 ahead of 55, but the compiler reports it as being 73, 12 ahead of 61 (the value it was reset to) and from a differnt file. This technique doesn't really work in this case as it doesn't take into account the extra lines added by RubyInline. The actual line in the source is 69.
A simple fix for this is to change the definition of the backtrack function to be just a C function rather than add it as a method on the object. Change builder.c to builder.prefix (on line 38 of your Ruby file). This won't work if you want to have backtrack available as a method on the object in Ruby. If that's the case you might need create another function to be the method, which then wraps the "real" backtrack function.
Next, looking at
./backtrack_inline.rb:67: error: lvalue required as unary '&' operand
This actually refers to line 61 of the generated code, which looks like:
char* s = StringValuePtr(rb_iv_get(self, "#seq"));
StringValuePtr is a macro which is defined as:
#define StringValue(v) rb_string_value(&(v))
This is where the & in lvalue required as unary '&' operand comes from. You need to add a local variable to be the lvalue:
VALUE seq = rb_iv_get(self, "#seq");
char* s = StringValuePtr(seq);
In my case (Mac OS X Snow Leopard, Ruby 1.9.3-p0, RubyInline 3.11.0) these two changes made the script run without errors, but gave the warning:
backtrack_inline.rb:47: warning: implicit conversion shortens 64-bit value into a 32-bit value
This actually refers to line 46 of the ruby file:
return (s - ss) - 1;
s and ss are char *, i.e. 64 bit pointers (on this machine), and the return type of the function is int - 32 bits. Adding an explicit cast fixed this:
return (int)((s - ss) - 1);
It now runs cleanly:
ruby-inline $ ruby backtrack_inline.rb
14
ruby-inline $
(I hope 14 is the correct answer!)
Here's a version of the script with these changes.
OK, the question was also answered at Ruby Forum:
http://www.ruby-forum.com/topic/2959614
Ok... thought a bit more about this.
you are calling a variable end. While this isn't a reserved word in C - and ruby shouldn't be looking at it... perhaps ruby is getting confused?
I'd suggest you have a go at renaming it just in case. Worthwhile trying even just to rule it out.