On Tue, Apr 10, 2012 at 1:00 PM, Dominique Dhumieres <[email protected]> wrote:
>> I don't know enough about Fortran to know whether the same issues arise
>> there. Perhaps in Fortran a common symbol is always a common symbol and
>> can never be a defined symbol. If that is the case then for Fortran I
>> think it would be safe to change the alignment of the common symbol. Of
>> course we would need to have some way to indicate that in the
>> middle-end--DECL_ALWAYS_COMMON or something.
>
> I don't know if this answers the question, but I have run the gfortran
> test suite with -fno-common and I have seen only one failure:
>
> [macbook] lin/test% gfc
> /opt/gcc/work/gcc/testsuite/gfortran.dg/global_vars_f90_init.f90
> /opt/gcc/work/gcc/testsuite/gfortran.dg/global_vars_f90_init_driver.c
> -fno-common -save-temps
> ld: duplicate symbol _i in global_vars_f90_init_driver.o and
> global_vars_f90_init.o
> collect2: error: ld returned 1 exit status
>
> AFAICT, COMMON is only lightly tested in the gfortran test suite and mostly
> for errors or warnings. However I find surprising that
> gfortran.dg/bind_c_coms.f90 + gfortran.dg/bind_c_coms_driver.c works:
-fno-common seems to be ignored by the fortran frontend, thus,
subroutine foo
common/BAR/ x
real(8) x
end
BAR is still a common decl with -fno-common. For your testcase only
the C compiled parts end up not using commons.
Thus the vectorizer would fail to promote the alignment of BAR regardless
of -f[no-]common. GFortran OTOH does
.comm bar_,8,16
for the above, thus aligns it to 16 already (to 32 with -mavx,
probably for vectorization).
So we should be fine.
Richard.
> [macbook] lin/test% gfc
> /opt/gcc/work/gcc/testsuite/gfortran.dg/bind_c_coms.f90
> /opt/gcc/work/gcc/testsuite/gfortran.dg/bind_c_coms_driver.c -fno-common
> [macbook] lin/test% a.out
> [macbook] lin/test%
>
> Dominique
