Re: proble with -fno-align-commons

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Feb 12, 2013 at 12:31 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Tue, Feb 12, 2013 at 11:14 AM, Tobias Burnus <burnus@net-b.de> wrote:
>> Maciej Skrzypek wrote:
>>>
>>> I am not sure whether I am sending this to a proper address, but I want to
>>> let you know that
>>> I encountered a problem with -fno-align-commons and quadruple precision
>>> variables:
>>> compiled with the -fno-align-commons option the program included below
>>> crashes with
>>> Segmentation fault (core dumped);
>>
>>
>> I have filled a problem report about it:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56293
>>
>> Nearly always, compiling with "-falign-commons" (the default) should be fine
>> and some hardware does not even support nonaligned variables. In any case,
>> nonaligned variables in common blocks are slower than aligned ones.
>>
>> In most code, using aligned commons should also not cause problems, it only
>> occurs for code like:
>>
>> ! One scoping unit (subroutine, function, data block):
>> character :: a
>> real :: x,y
>> common /foo/ a,x,y
>>
>> ! Another scoping unit
>> character :: b(5)
>> real :: r
>> common /foo/ b,r
>>
>> That's what one gets without padding/aligning:
>> axxxxyyyy
>
> Does GFortran then properly set alignment on the accesses?  That is,
> the original reported case shouldn't cause an alignment fault unless
> the frontend lies to the middle-end about the alignment of sss.p

So the issue is obviously:

  static integer(kind=4) i [value-expr: sss.i];
  static real(kind=16) p [value-expr: sss.p];

  {
    struct __st_parameter_dt dt_parm.0;

    dt_parm.0.common.filename = &"t.f90"[1]{lb: 1 sz: 1};
    dt_parm.0.common.line = 5;
    dt_parm.0.common.flags = 128;
    dt_parm.0.common.unit = 6;
    _gfortran_st_write (&dt_parm.0);
    _gfortran_transfer_real128_write (&dt_parm.0, &p, 16);

you pass a pointer to an unaligned read(kind=16) to
_gfortran_transfer_real128_write which expects a properly aligned pointer.

The only way to avoid this is to copy the value from p to a properly aligned
temporary and then print that value.  Of course as write is very fancy
handling all possible cases correctly is going to be interesting ;)

libgfortran assumes that all data is properly aligned, which is a valid
assumption.

I suggest to deprecate and remove -fno-align-commons.

Richard.

> Richard.
>
>> bbbbbrrrr
>> However, with aligning/padding one has
>> a___xxxxyyyy
>> bbbbb___rrrr
>>
>> ["_" denotes padding bytes, which are physically present but not associated
>> with a variable (in a given scoping unit).]
>>
>> Thus, if one only uses "a" <-> "b(1)" and "r"<->"y" for 'data transfer'
>> between scoping units , it should work fine, if one uses "b(2)" to "b(5)" to
>> access "x" it won't work. As such code is not very common, it is likely that
>> -falign-commons just works fine with nearly all real-world code. (In any
>> case: Do not mix code compiled with -falign-commons and -fno-align-commons,
>> at least if both share the same (named or blank) common block.
>>
>> Tobias