This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: reorder elements or use -fno-align-commons


Jack,

Take a look at PR37614 + http://gcc.gnu.org/ml/fortran/2009-01/msg00217.html

The present packing maintains g77 compatibility.  We intend for 4.5 to
join the pack :-) and leave the leading padding off.

Cheers

Paul

On Tue, Jan 20, 2009 at 1:56 AM, William B. Clodius
<wclodius@los-alamos.net> wrote:
>
> On Jan 19, 2009, at 4:42 PM, Jack Howarth wrote:
>
>>  What exactly are the implications of warnings like...
>>
>>   Included at xadc.f:785:
>>
>>     COMMON /IXADC1/  EXPXADCPTRS,
>>                    1
>> Warning: COMMON 'ixadc1' at (1) requires 4 bytes of padding at start;
>> reorder elements or use -fno-align-commons
>> xadc.fcm:75.21:
>>
>> ...from current gcc trunk. I see a number of these warnings when compiling
>> xplor-nih
>> but they don't seem to be associated with any regressions. Do these
>> warnings imply a
>> possible wrong-code generation because of the incorrect alignment or just
>> a suboptimal
>> ability for gfortran to do code optimizations? Thanks in advance for any
>> clarifications
>> on this warning.
>>         Jack
>>
> In this case it implies a suboptimal use of storage. Generally every data
> type has an optimal alignment, such that not placing an object of that type
> at an aligned memory location has a substantial performance impact. For the
> intrinsic Fortran data types this alignment is typically a multiple of the
> size of the data type. In order to ensure efficient operation, padding
> (unused small regions of memory) can be used to align larger objects. The
> default in Fortran compilers is typically to optimize performance and not
> memory usage. The semantics of common blocks is such that (baring whole
> program optimization) the objects must be laid out in sequence. Further some
> common abuses of common blocks assume no padding between objects in the
> block, and by default all compilers avoid inserting such padding. In any
> event you will typically get the optimal combination of performance and
> memory usage if the objects in the block are in the order largest to
> smallest. This message indicates that you have smaller objects before a
> larger object, and the compiler is inserting padding a the start so that
> larger object is properly aligned for optimal performance.
>



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]