Hi, that is what I get when I run my program
PGFIO-F-231/formatted read/internal file/error on data conversion.
In source file r2v435.f, at line number 3980
And here is the code:
.
.
3979 FORMAT(‘(I’,I2,‘)’)
3980 READ(IBUF,IFOR) INT(I)
3981 ELSE IF(TYPE(1:9).EQ.‘CHARACTER’) THEN
.
.
.
I don’t get the error when I run it with Intel Fortran Compiler.
Any suggestions will be more than welcomed.
Cheers, Alberto.
no ideas??? please. . .
Hi Betal,
What’s the value of the format string “IFOR”?
Hey, that’s what I get when I use GDB, hope it can help … .
3980 READ(IBUF,IFOR) INT(I)
Current language: auto; currently fortran
(gdb) print I
$1 = 1
(gdb) print IBUF
$2 = ‘0\r’, ’ ’ <repeats 75 times>
(gdb) print IFOR
$3 = ('(I 2) ')
(gdb) next
PGFIO-F-231/formatted read/internal file/error on data conversion.
In source file r2v435.f, at line number 3980
Program exited with code 0177.
strange. . . isn’t it?? this thing is driving me crazy. .
Are you getting read and write mixed up?
Or, maybe there is a space between ‘I’ and ‘2’ above (or maybe just it looks that way on this forum page…)
brentl@hawaii:~> more uf.f
program uf
real i
integer j
character10 a
character10 IFOR
IFOR = ‘(I2)’
i = 7.0
write(a,ifor) int(i)
print *,a
read(a,ifor) j
print *,j
end
brentl@hawaii:~> pgf90 uf.f
brentl@hawaii:~> ./a.out
7
7
An extra information. . . the problem appears when I’m working on Linux. When I compile it and run it under windows it works fine.
Any ideasss???
Hi betal,
As Brent points out, it doesn’t make sense to read into the result of an intrinsic function (INT). So I think the error is correct. Does the error go away if you remove the “INT” intrinsic?
The error goes away If I run the program on windows(with PGI). The semantic of the program is correct because I didn’t write the program and it works fine on windows(exactly the same code).
That’s why I blame the Linux implementation of the PGI compiler for the error(Intel Linux compiler also works well with the code).
I’ll try changing the linux distro, may be a problem of codification of the file???.
Cheers, Alberto
Hi Alberto,
Instead of speculating, can you please send the code to trs@pgroup.com and ask customer support to forward it to me?
Thanks,
Mat
OK, in a second. Thank you.
David, after debugging the program for a while I think I found the error. It seems to be a calling convention problem.
I did the following:
1)compile and debug a linux and a windows version of the program in differents machines.
2)check the values of the parameters before the call to routine crack in line 11555 in both programs. The values where the same.
3)check the values of the parameters just after entering the routine. The values where quite different with uninitialized variables as you pointed before.
Besides the code does not adhere to the standard I think that parameters should be passed anyway. May be a non-standard way of calling the subroutine??.
I will appreciate if you can make me know anything regarding to solving my problem.
Cheers, Alberto.
May be a bug in the compiler???
please don’t leave me alone…
Ok, I think I figured this one out. It’s not the INT(I) as Brent and I thought since your INT is a local integer array, not the INT intrinsic. The problem is that the input file is formatted for DOS and contains a carriage return and linefeed. So when the data is read in, a “\r” is being added to IBUF. Since “\r” is a character, the write into an integer fails. The fix it to run the utility “dos2unix” on your data file.