Home > Archive > Fortran > September 2005 > Warning: Because of COMMON...............
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Warning: Because of COMMON...............
|
|
| nancy80 2005-09-20, 7:02 pm |
| I am trying to compile the source code of DRAIN-2DX (an engineering free
software availiable in nisee site).However I am getting 1231 warning
messages of the following type:
Warning: Because of COMMON, the alignment of object is inconsistent with
its type [PKG]
9 FR0(2),CR0(2),FRA(2,2),CRA(2,2),CPIN(2,2
),FPIN(2,2),PKG,PKGP,RSum
Can anyone help me with this problem?Although an executable can be created
it does not work.....
| |
| glen herrmannsfeldt 2005-09-20, 7:02 pm |
| nancy80 wrote:
> I am trying to compile the source code of DRAIN-2DX (an engineering free
> software availiable in nisee site).However I am getting 1231 warning
> messages of the following type:
> Warning: Because of COMMON, the alignment of object is inconsistent with
> its type [PKG]
> 9 FR0(2),CR0(2),FRA(2,2),CRA(2,2),CPIN(2,2
),FPIN(2,2),PKG,PKGP,RSum
> Can anyone help me with this problem?Although an executable can be created
> it does not work.....
Arrange the variables in COMMON so that all DOUBLE PRECISION come first,
then all default sized variables, then, if you have any, INTEGER*2's,
and finally any *1 variables. CHARACTER variables, if any, should
also be at the end.
If the program uses any tricks related to EQUIVALENCE and COMMON, where
variables overlap in unexpected ways, it will be somewhat harder.
If you find COMMON statements are not consistent between routines, such
as not all being the same length, it will also be a little harder, but
probably the best thing then is to make them all the same.
Which machine are you running on? x86 doesn't require alignment, but
many RISC processors do.
-- glen
| |
| nancy80 2005-09-21, 3:56 am |
| Thank you for your reply glen.However, my concern is why a source code
which was supposed to function well (as it is given from an official site)
it does not.Do you think that this has to do with using a newer compiler? I
am finding it quite hard to fix the problem....The variables are so
many.........
| |
| glen herrmannsfeldt 2005-09-21, 7:57 am |
| nancy80 wrote:
> Thank you for your reply glen.However, my concern is why a source code
> which was supposed to function well (as it is given from an official site)
> it does not.Do you think that this has to do with using a newer compiler? I
> am finding it quite hard to fix the problem....The variables are so
> many.........
Not all machines require variables to be aligned, and people
using such machines aren't always very good about doing it.
What machine are you running on?
Intel x86 processors don't require alignment, though they usually
run much faster on aligned data.
If there are an even number of REAL or INTEGER variables before each
DOUBLE PRECISION variable it should also work. You might also
add dummy variables.
Are the COMMON statements the same in all routines? That will make
it much easier to fix, and remain consistent.
-- glen
| |
| glen herrmannsfeldt 2005-09-21, 7:57 am |
| nancy80 wrote:
> Thank you for your reply glen.However, my concern is why a source code
> which was supposed to function well (as it is given from an official site)
> it does not.Do you think that this has to do with using a newer compiler? I
> am finding it quite hard to fix the problem....The variables are so
> many.........
Never mind, I looked at the COMMONs.
There are INTEGER*2 variable, not standard but many older programs used
them. There is even a variable indicating the ratio of the size of a
real to the size of an integer, which means it is likely doing many
non-standard tricks with different kinds of variables.
I am not so sure that this is the cause of your problem, especially
if you are on an x86 machine. Is PKG the only one it is warning about?
It might be best to find which machine and compiler they used, and
try to use the same one, at least to see it work once.
-- glen
| |
| nancy80 2005-09-21, 7:57 am |
| Glen thanks again for your reply.I am on a x86 Intel machine. No luck until
now.I am trying to use the Salford Plato 3 compiler to see if something
will change.It seems my problem requires advance programming skills i do
not have. While ignoring the warnings and build the executable ,trying to
run the program produces an error for array bounds.Any other ideas?
| |
|
|
| nancy80 2005-09-21, 7:57 am |
| Can you have a look in the source code?You can find it
in:http://nisee.berkeley.edu/software/drain2dx/
Actually I want to change a parameter in the exe file.That's why i want to
rebuild the given executableT
Thanks
| |
| Herman D. Knoble 2005-09-21, 7:57 am |
| Nancy: For most current systems, that a COMMON variable's address
is not divisable by it's type (length), won't prevent the program
from compiling. As Glen pointed out, the best strategy here is to
make all COMMONS and companion declarations the same in all program
units. This is sometimes done by use of INCLUDE of the declaratons
and COMMON statements. If the variable names in COMMON are different
between program units, this precludes use of INCLUDE and also increases
the chances for program problems related to mapping of the variables
in COMMON; for example, undefined variables, wrong answers,
overwriting of arrays, etc.
Regards.
Skip Knoble
On Wed, 21 Sep 2005 04:16:09 -0400, "nancy80" <nkazantzi@yahoo.com> wrote:
-|Thank you for your reply glen.However, my concern is why a source code
-|which was supposed to function well (as it is given from an official site)
-|it does not.Do you think that this has to do with using a newer compiler? I
-|am finding it quite hard to fix the problem....The variables are so
-|many.........
| |
| David Jones 2005-09-21, 6:59 pm |
| nancy80 wrote:
> Glen thanks again for your reply.I am on a x86 Intel machine. No
luck
> until now.I am trying to use the Salford Plato 3 compiler to see if
> something will change.It seems my problem requires advance
> programming skills i do not have. While ignoring the warnings and
> build the executable ,trying to run the program produces an error
for
> array bounds.Any other ideas?
Have you checked to see if your compiler has any options that affect
allignment of items in common blocks?
| |
|
| "nancy80" <nkazantzi@yahoo.com> wrote in message
news:2d59bab58794bc559757f72eb046306d@lo
calhost.talkaboutprogramming.com...
> Can you have a look in the source code?You can find it
> in:http://nisee.berkeley.edu/software/drain2dx/
OK
I'm using DVF on Windows XP. Intel processor.
I downloaded the source and one by one set up projects for each
subdirectory. I got as far as ELEM07 and got the alignment errors you
reported.
The "offending" include file is infel07.h common /infel/
Several of the include files (in subdirectory common and other ELEMxx
directories) have the named common block "infel".
And each include file has a different set of variable names for that common.
There is no "implicit none", neither are the variables given explicit data
types so assumed data types will be used [integer (for variable names
beginning with I through N) and real (variable names beginning with A
through H, and O though Z) ]
Without looking more closely at the code I cannot tell whether the various
uses of the common blocks are isolated and independant, or whether data
values are carried across from one sub-directory to another (in the CALLing
sense).
So there appears to be no simple answer to your problem. Though since they
are warnings it should be ok to ignore them.
As an aside, and purely a style issue :
When I used common (before modules) I preferred to have one common for
integer, one for real, one for logical and one for character data.
eg
common /infel_I/ .... integer data
common /infel_R/ .... real data
etc.
Making life much easier for adding/removing items without too many of these
alignment problems.
Les
| |
| Tim Prince 2005-09-21, 6:59 pm |
| Les wrote:
> "nancy80" <nkazantzi@yahoo.com> wrote in message
> news:2d59bab58794bc559757f72eb046306d@lo
calhost.talkaboutprogramming.com...
>
>
>
> OK
> I'm using DVF on Windows XP. Intel processor.
> I downloaded the source and one by one set up projects for each
> subdirectory. I got as far as ELEM07 and got the alignment errors you
> reported.
> The "offending" include file is infel07.h common /infel/
>
> Several of the include files (in subdirectory common and other ELEMxx
> directories) have the named common block "infel".
> And each include file has a different set of variable names for that common.
>
> There is no "implicit none", neither are the variables given explicit data
> types so assumed data types will be used [integer (for variable names
> beginning with I through N) and real (variable names beginning with A
> through H, and O though Z) ]
>
> Without looking more closely at the code I cannot tell whether the various
> uses of the common blocks are isolated and independant, or whether data
> values are carried across from one sub-directory to another (in the CALLing
> sense).
>
> So there appears to be no simple answer to your problem. Though since they
> are warnings it should be ok to ignore them.
>
> As an aside, and purely a style issue :
> When I used common (before modules) I preferred to have one common for
> integer, one for real, one for logical and one for character data.
> eg
> common /infel_I/ .... integer data
> common /infel_R/ .... real data
> etc.
> Making life much easier for adding/removing items without too many of these
> alignment problems.
>
>
The standard did not support half-size integers, or use of CHARACTER
along with
numeric data types in COMMON. As this application shows, it would be
possible
to combine violations of the standard and standard practice with lack of
adequate testing, so as to ensure unreliability on future platforms.
| |
| glen herrmannsfeldt 2005-09-21, 7:00 pm |
| nancy80 wrote:
> Glen thanks again for your reply.I am on a x86 Intel machine. No luck until
> now.I am trying to use the Salford Plato 3 compiler to see if something
> will change.It seems my problem requires advance programming skills i do
> not have. While ignoring the warnings and build the executable ,trying to
> run the program produces an error for array bounds.Any other ideas?
On x86 intel processors alignment is a warning, so for now don't
worry so much about them.
If it is just alignment it should not cause array bounds problems.
Worse than alignment problems, though, is having different COMMON
blocks in different routines not matching up with each other.
That shouldn't be compiler dependent, but it is possible, and
could easily cause array bounds problems.
If you can find out which compiler was used before to supposedly
correctly compile this, I would try to use that. Even so, I
would not be surprised if there are a large number of bugs left
in this program. At one point I saw a ten line COMMON statement
followed by comments describing how many integer, real, and
character variables were on each of nine lines. It seems that
some had been added without updating the comment.
It might be that many changes have been made by many different
people without understanding the interaction between them.
To really fix this program would probably take years.
-- glen
|
|
|
|
|