http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52835
Tobias Burnus <burnus at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Keywords| |wrong-code Last reconfirmed| |2012-04-02 Component|fortran |middle-end CC| |burnus at gcc dot gnu.org Ever Confirmed|0 |1 Summary|Incorrect code generated by |[4.7/4.8 Regression] -O3 |gfortran 4.7.0 |wrongly optimizes loop | |__builtin_memcpy away Target Milestone|--- |4.7.1 --- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-04-02 16:11:37 UTC --- Confirmed - and smells rather like a middle-end issue. (Or a rather convoluted FE declaration bug.) Works with my 2011-12-24-r182676 build Fails with my 2012-02-28-r184613 build (Note: Those contained some patches, which shouldn'tâ„¢ affect the result.) * * * Works with: gfortran -fdump-tree-optimized -funswitch-loops -fpredictive-commoning -fgcse-after-reload -ftree-vectorize -finline-functions -fipa-cp-clone -O2 (And fails with -O3 and the -fno-* version of those flags.) Thus, none of the specific flags which get enabled with -O3 seems too blame. * * * Looking at the optimized dump, the loop DO IS=1,MS ISU(IS)=0 ZSPM(IS)=' ' RSV(IS) =0.0 ENDDO gets replaced by: __builtin_memset (D.1976_27, 0, 12); __builtin_memset (D.1956_11, 0, 12); That's almost fine, however, the ZSPM(is) = ' ' is lacking. With -O2 one finds in the loop: __builtin_memcpy (D.2078_113, &" "[0], 8); Note that ZSPM is an array of size 3 of character strings of length 8: character(len=8) :: ZSPM(MS) where "MS" is 3. The best (optimized) version would be something like "memset(ZSPM, " ", 3*8);". In 4.6, one had (with -O3) and expanded loop with the following for [0], [1] and [2]: D.1697_89 = &MEM[(character(kind=1)[0:D.1598][1:8] *)D.1577_23][0]; __builtin_memcpy (D.1697_89, &" "[0], 8);