Porting fortran program-problem with padding in common

[saleemhasan]

Hello,

I must start by stating that I know almost nothing about fortran. I am trying to help port a fortran program to linux. It compiles and runs fine on irix (64 bit sgi origin 2000). There are two make files and both of them give padding warnings.
---------
Padding of 4 bytes required before `eln' in common block `option' at (^) -- consider reordering members, largest-type-size first
---------

I searched the Internet and found that in order to improve performance and to minimize the number of cpu fetches, padding is needed if variables are not stored from the largest type-size to the smallest. Since the program is very large, it is not possible to re-arrange the order of the variables from large to small in the COMMON blocks. I found a couple of options (for different compilers) that align (pad) the storage however, none of these options worked on my compilers. I tried these options on a Centos 5.9 linux and a Redhat EL 5 machine.

I entered the align option in the make file.

maindpx.exe: maindpx.o exerfc.o saxbi.o tred2.o cavxcor.o diagovlp.o
f77 -o32 -falign-commons -o maindpx.exe maindpx.o exerfc.o saxbi.o tred2.o cavxcor.o diagovlp.o

maindpx.o: maindpx.f
f77 -o32 -c maindpx.f
exerfc.o: exerfc.f
f77 -o32 -c exerfc.f
.....
....

I tried -falign-commons from a gnu fortran compiler site
I also tried -fno-align-commons to prevent the compiler from padding but there was no change. I got the same warnings. I tried a couple of other versions of the same option such as -aligncommon[=4 or 8] but that did not help.

Is it that I am entering the option on the wrong line?

Thank you very much in advance for your help.

Saleem

 

[SteamKing]

When all else fails, read the instructions. Your system must have some documentation for running the compiler.

 

[saleemhasan]

I will try that option next SteamKing.
Thank you.

 

[gsal]

I had to do something like that last time I had to port from Solaris to Linux...I thought re-ordering was cleaner than needing a compilation flag, so I did...it is not impossible ;-)

There are only 2 variable lengths, integers and reals...all you got to do is move the integers to the back of the common block or, better yet, split the common block into two by type...o.k., there may be more lengths if you have character variables or various lengths within a type (REAL*4, REAL*8, etc)...but it is very do-able and it is called programming :-)

 

[saleemhasan]

gsal,

Thank you for the encouragement to take the "re-ordering" path. I think it will be a slow and painful one but I will try that also. In the programs that I am trying to port, I think there are more than just two variable lengths. There are doubles and chars also.

Is it correct to say that aligning messages are all warnings and could be ignored temporarily. It would only result in some loss in performance?

The reason I want to set aside the aligning (if they are only warnings) is that, there is an Error, in addition to the align messages. It is about ambiguity in Real (double) variable. However, I will start another thread for that and provide more details. As I had mentioned in my original post, the program works on sgi irix and so all these warnings and the error are porting issues.

I think I will change my username to porter :).
Although, this is my first attempt, people who do porting should have a separate designation and not be lumped in with programmers :)

 

[SteamKing]

Errors will keep you from building and running your application. These must be fixed. Warnings are not as serious, and will not prevent you from building and testing the application.

 

[saleemhasan]

Thank you. That is what I thought. I will postpone the align (padding) issues that seem to be warnings only. I will first try to correct the error.

 

[gsal]

http://www.delorie.com/gnu/docs/gcc/g77_567.html

http://cepa.fnal.gov/psm/simulation/mcfast/version_doc/v5_2/simulator/alignment_notes.html

By the way, I am not 100% sure that a problem with alignment is always just a warning...I wonder if it could become more than a performance problem and become a real memory problem as things get misplaced...but I don't know that much.

Sometimes, when not knowing the answer, is just as valuable to know how to stay away from trouble.

gsal

 

[saleemhasan]

gsal,
Thank you for the warning. The reason I am switching to solving the other problem of ambiguity of real is because this one appears to be an error. I cannot compile until I get rid of it. As you stated, it is quite possible that after correcting the error the many warnings on padding (align) may still prevent the program from running.