#6375: Because of COMMON, the alignment of object is inconsistent with its type

[daninraleigh]

I feel horrible about asking this question, but I am now at a company that is now(finally) wanting to upgrade from MS Developer Studio PowerStation 4.0. As would be expected, I am running into quite a number of Errors and Warnings. Is there any sort of documentation on any statement conversions?

Here is one of the issues I have run into so far(hundreds of these):


Warning 1 warning #6375: Because of COMMON, the alignment of object is inconsistent with its type [SM_MAP] ..\Include2\SM_MAST.FI

This occurs where we have declared the following:

REAL*4 SM_MAP(8)

with a COMMON statement similar to this:

COMMON /SM_CBUF/ SM_MAP ,SM_GROUP,...


or another example:

INTEGER SP_DEVIDSEQ *4


COMMON /S1_CBUF/ SP_ID1 ,SP_DEVIDSEQ, ...

[TimP]

Quoting - daninraleigh

Warning 1 warning #6375: Because of COMMON, the alignment of object is inconsistent with its type [SM_MAP] ..Include2SM_MAST.FI

This occurs where we have declared the following:

REAL*4 SM_MAP(8)

with a COMMON statement similar to this:

COMMON /SM_CBUF/ SM_MAP ,SM_GROUP,...


or another example:

INTEGER SP_DEVIDSEQ *4


COMMON /S1_CBUF/ SP_ID1 ,SP_DEVIDSEQ, ...

Such a problem would be expected where padding would be needed in order to place the data at an address which is a multiple of the number of bytes required to store it. You haven't showed enough of the problem to understand it. In the last case, if you declared SP_ID1 as a CHARACTER string, or as INTEGER*2, that might account for the problem.
ifort 11, with the IPO options, wants to pad COMMON so that all objects fall on 8-byte boundaries. Then, in your last case, even if SP_ID1 has a 32-bit KIND, there would be padding added if it had an odd number of elements. If your code depends on avoiding padding, you must set /Qipo- .

[Steven_L_Intel1]

I'm unsure why Tim suggested /Qipo- - that doesn't seem relevant to me, but perhaps I overlooked something.

In any event - the warnings you show are alerting you that performance may suffer because you have forced variables to be allocated at memory addresses that are not multiples of the data type size. This will not affect correctness and you can ignore the warnings if you don't want to rearrange the COMMON. You can disable the alignment warnings in the project properties under Diagnostics.

You say you get errors but did not elaborate - what are they?

[TimP]

Quoting - Steve Lionel (Intel)

I'm unsure why Tim suggested /Qipo- - that doesn't seem relevant to me, but perhaps I overlooked something.

I assumed one reason for the warning would be in case the program made assumptions about COMMON layout. The examples don't indicate whether that would be a problem. If it were, you would be concerned about the padding which /Qipo would insert. In the case we ran into, an alternative to suppress padding (and some other optimizations) while keeping /Qipo was to set /Qansi-alias-. I do wonder why that has such an effect.

[Steven_L_Intel1]

By default, the compiler does not padd COMMONs. To some degree, it's not allowed to by the Fortran standard. We do have options which allow you to specify padding of COMMONs for alignment.

[Richard_Conn_H_]

Quoting - daninraleigh

Steve Lionel, I am totally naive: you say "You can disable the alignment warnings in the project properties under Diagnostics." but I haven't the slightest idea how to do that (and I'd like to, very much, get rid of those warnings)

Dick Henry henry@jhu.edu Macintosh

SI feel horrible about asking this question, but I am now at a company that is now(finally) wanting to upgrade from MS Developer Studio PowerStation 4.0. As would be expected, I am running into quite a number of Errors and Warnings. Is there any sort of documentation on any statement conversions?

Here is one of the issues I have run into so far(hundreds of these):


Warning 1 warning #6375: Because of COMMON, the alignment of object is inconsistent with its type [SM_MAP] ..Include2SM_MAST.FI

This occurs where we have declared the following:

REAL*4 SM_MAP(8)

with a COMMON statement similar to this:

COMMON /SM_CBUF/ SM_MAP ,SM_GROUP,...


or another example:

INTEGER SP_DEVIDSEQ *4


COMMON /S1_CBUF/ SP_ID1 ,SP_DEVIDSEQ, ...

[Steven_L_Intel1]

Dick Henry,

You included "Macintosh" in your post - are you using Intel Fortran for Mac OS X? If so, add the switch:

-warn noalign

and the warning should go away. If you are using Windows (this forum is for the Windows compiler), in Visual Studio, right click on the Fortran project, select {Properties, Fortran, Diagnostics. Scroll down to "Warn for unaligned data. Click on the "Yes" and change it to "Np".

[TimP]

Quoting - Steve Lionel (Intel)

By default, the compiler does not padd COMMONs. To some degree, it's not allowed to by the Fortran standard. We do have options which allow you to specify padding of COMMONs for alignment.

Steve rightly advocates preventing /Qipo from affecting assumptions about alignment.
Performance implications of COMMON alignments, and those warnings, may be avoided by the traditional scheme of laying out COMMON in decreasing order of data type size, and following f77 rules about no mixing of CHARACTER and numeric data types in the same COMMON.

[Richard_Conn_H_]

Quoting - Steve Lionel (Intel)

Dick Henry,

You included "Macintosh" in your post - are you using Intel Fortran for Mac OS X? If so, add the switch:

-warn noalign

and the warning should go away. If you are using Windows (this forum is for the Windows compiler), in Visual Studio, right click on the Fortran project, select {Properties, Fortran, Diagnostics. Scroll down to "Warn for unaligned data. Click on the "Yes" and change it to "Np".

Steve, thanks! I am indeed Macintosh. I stumbled into this board just by googling "warning #6375" which I did because I was so annoyed at a raft of such warnings in one of my programs. I just now used your -warn noalign and it worked perfectly!

But even bigger thanks to tim18 - I broke the common into TWO separate common statements, one for the integer arrays, one for the CHARACTER arrays, and ... no warnings! tim18, it is a blessing not to have to type -warn noalign each time!

As long as I'm replying, I might tell my story: when I entered University of Toronto as a freshman in the fall of 1957 the U of T owned ONE computer. Professor Don MacRae, bless him, had all the astronomy students program that computer, in an assembly language called SOAP (I know there was something else, also called SOAP, later). And I vividly remember in 1959 another student telling me that something called FORTRAN was coming along. I've been programming fortran ever since and I bless Intel for letting me do it on my blessed Mac (Windows, ugh! - oops, apologies!)

Let me see if I can impress you, at all, with what I do in fortran:

item: http://henry.pha.jhu.edu/henryMinkowski.pdf

that poster was generated in fortran, writing postscript (the photos are pasted into the .eps file)

item: http://henry.pha.jhu.edu/zip/21218.html

try typing in you own zip code - my fortran program generates this for every zip code in the continental US, takes just a few minutes to update as needed. The joke page is pretty lame - suggestions welcome

item: http://henry.pha.jhu.edu/forum.html

that is my family tree web site - the fortran program generates all the pages in less than two minutes when I update the flat file with the individual people.

item: http://henry.pha.jhu.edu/calendarDir/julianDir/julian.html

calendar for thousands of years, all generated from fortran

Sorry for wandering off topic, but I do love fortran, and I'm grateful for your help!

Actually, that reminds me: I find the documentation for fortran very hard to use. I wish someone would publish a "Friendly guide to Intel Fortran."

Cheers,

Dick Henry

[Steven_L_Intel1]

Dick,

I'm glad that you straightened it out.

Do you have specific suggestions for the documentation? Have you read the "Getting Started with Intel Fortran" document?

[Richard_Conn_H_]

Quoting - Steve Lionel (Intel)

Dick,

I'm glad that you straightened it out.

Do you have specific suggestions for the documentation? Have you read the "Getting Started with Intel Fortran" document?

Yes, I have. I don't find it helpful at all. Like Winnie the Pooh, I am a bear of very little brain!

What I used on the Mac for years was Language Systems Fortran, and I loved it. It had a couple of sample programs that I copied and adapted. This was before Mac had OSX and a command line: I had very mixed feelings about the transition, for fear I'd lose my fortran (which would be tragic for me). But it has worked out fine, first with IBM fortran, and now with Intel. I admit I'm slightly annoyed that I have to type ifort intead of fort, but I can live with that! And I'd like to just be able to type ifort program.f instead of ifort program.f90 (because the 90 is irritating to type), but I can live with that too. And over the years I've slowly trained myself to type everything in lower case - long ago ALL FORTRAN WAS UPPER CASE for some reason that escapes me. And I learned to use ! for comments instead of c.

Language Systems Fortran let me write to the screen directly from the program. I can't do that with Intel, but in practice that does not limit me at all, I can do what I need to do.

I did try using Xcode, and succeeded in doing the same thing that I do from the command line, but nothing more than that, so why bother with Xcode.

I did have some ambition to learn how to use Xcode to generate windows etc. etc. but I don't have a sample Xcode program THAT CALLS A FORTRAN PROGRAM to adapt to my needs, and I'm not up to really learning Xcode use. This is not a problem for me, as things stand.

Language Systems Fortran was simply an Application for the Mac, like Microsoft Word, or anything else. No use of X11 etc. and no need to have Developer Tools (or now Xcode). But I'm happy, I can do my thing!

Cheers,

Dick Henry

[Steven_L_Intel1]

Ok. If you need help in the future, please visit our Mac OS (and Linux) Fortran forum.