On Tue, Apr 10, 2012 at 1:00 PM, Dominique Dhumieres <domi...@lps.ens.fr> 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