we are currently migrating to F90 from F77 fortran.
When I link the code, I get link error on index function with f90 compiler, but it works fine with F77.
Symbol not found error
Can you please tell where can I find the symbol definition.
The routine __f_index_a resides in the main Fortran support library libfsu. If you link your program using the commands f90 or f95, libfsu will automatically be linked with your program unless you specify an option, such as -nolib, to prevent it from doing so.
I have one more question on the behaviour of real*8 number in F90 versus F77. Here is my code:_
print *, R8
R8=tprice * *1000000.* // this has dot(.) at the end
print *, R8
When I compile and link it in F90 the result is
When I compile and link it in F77 the result is
The only difference in the compilation parameter is [ -i2 parameter in F77 and -xtypemap=integer:16 in F90 ]: F77: f77 -c -g -w -i2 -misalign -u -w66 driver.f F90: /opt/solstudio12.2/bin/f90 -c -g -w -u -f77=%all -ftrap=%none -xtypemap=integer:16 driver.f
please advice on what should we do inorder to get the same result without code changes.
Edited by: 905073 on Jan 11, 2012 11:15 AM
The problem is that the constant 1000000 does not fit in 16 bits. The value of a constant that is out-of-range is undefined. If you had not suppressed warnings, the compiler would have told you
WARNING: This numeric constant is out of range.
Since you want it to work without changing the source code, I suggest deleting the option -xtypemap=integer:16. If the program works properly without the option, you will be better off for having dropped it.
If you were willing to change the source code, I would suggest change the constant to
Thanks Robert for the very prompt reply.
Understood, we will still need -i2 option or -xtypemap=integer:16, as most of our legacy code does not have Implcit integer*2 in the code.
but you pointed out a good way by unsuppressing the warning message, so I can manually correct the code, I am pretty sure it is not in many place, I can manualy update the code.
I was just curious why it worked with F77 and not with F90 ?
I see that the compiler option "-misalign" is not supported in F90, do you know the alternative for -misalign ?
i tried -dalign & -xmemalign, but it does not work similar to -misalign.
The f77 compiler's option -misalign should be equivalent to -xmemalign=1i. Is that what you tried? If so, how was it different from -misalign?
The option -dalign increases the required alignments.
As I mentioned before, the value of a constant that does not fit in the space allocated for it is undefined. Different compilers will handle it differently.
Sun's f77 compiler was derived from the BSD UNIX f77 compiler, which in turn was derived from AT&T's f77 compiler. AT&T's f77 compiler was written by Stuart Feldman while he was at Bell Labs. Perhaps influenced by the C programming language, he chose to increase the space allocated for an integer constant if its value did not fit in the space that would normally be allocated for it, up to the size of the largest supported integer type.
Sun's f90 and f95 compilers were derived from the CraySoft f90 compiler. The CraySoft compiler chopped off the high-order bits of integer values that did not fit in the available space.
Sun's Fortran team recognized that the behavior of Sun f90 and f95 in this regard would be a problem for some users. We devised a scheme that would resolve the problem in most cases. The scheme has been partially implemented, but there is still a lot of work left to be done.
When I compile the program with compiler option -xmemalign=1i and without -w
I see the following warning message:
WARNING: Object "XXXXXXXX" has bad alignment forced by equivalence.
This warning is similar to what I see without -xmemalign=1i, so this option is not alternative for -misalign used in F77 compiler.
Now, I compile the program with compiler option -aligncommon and without -w, I donot see any warning message for alignment.
so, I think -aligncommon looks to be alternative for -misalign used in F77 compiler.
The option -aligncommon is equivalent to the option -aligncommon=1, which forces common variables to be allocated without any padding inserted between the variables. That might be what you want. If you are running on a machine with a SPARC CPU, you are likely to still need the option -xmemalign=1i, or another memalign option with the i suffix. The suffix enables a user trap handler that fixes up unaligned data references. For x86 or x64 CPUs, the CPU fixes up unlaigned data references unless you tell it not to.