[Bug fortran/51267] New: loop optimization error using LOC function

[Bug fortran/51267] New: loop optimization error using LOC function

[priv123 at hotmail dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

             Bug #: 51267
           Summary: loop optimization error using LOC function
    Classification: Unclassified
           Product: gcc
           Version: 4.6.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: priv123@hotmail.fr


Created attachment 25880
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25880
simple source file

The small program attached fails using gfortran 4.6.1 (ubuntu oneiric built)
using -O1 optimization level or higher (ok at -O0).
It succeeds with gfortran 4.5.4 at all -O levels.

It ends by printing a boolean value : T if the test is ok, F else.

$ gfortran-4.5 -O1 -Wall -Wextra bug46_stat.f ; ./a.out
 tab(           1 )=          -1
 tab(           2 )=          -1
 tab(           3 )=          -1
 tab(           4 )=          -1
 tab(           5 )=          -1
 tab(           6 )=          -1
 T

$ gfortran-4.6 -O1 -Wall -Wextra bug46_stat.f ; ./a.out
 tab(           1 )=   134520832
 tab(           2 )=    10813028
 tab(           3 )=          -1
 tab(           4 )=           0
 tab(           5 )=    10870894
 tab(           6 )=          -1
 F


Ouput with '-v' : 

Driving: gfortran-4.6 -v -save-temps -O1 -Wall -Wextra prog_stat.F -l gfortran
-l m -shared-libgcc
Utilisation des specs internes.
COLLECT_GCC=gfortran-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper
Target: i686-linux-gnu
Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin
--enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=i686-linux-gnu
--host=i686-linux-gnu --target=i686-linux-gnu
Modèle de thread: posix
gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.6.1/f951 prog_stat.F -ffixed-form
-cpp=prog_stat.f90 -quiet -v -imultilib . -imultiarch i386-linux-gnu
prog_stat.F -quiet -dumpbase prog_stat.F -mtune=generic -march=i686 -auxbase
prog_stat -O1 -Wall -Wextra -version -fintrinsic-modules-path
/usr/lib/gcc/i686-linux-gnu/4.6.1/finclude -o prog_stat.s
GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (i686-linux-gnu)
    compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
heuristiques GGC: --param ggc-min-expand=81 --param ggc-min-heapsize=95876
le répertoire « /usr/local/include/i386-linux-gnu » est ignoré car inexistant
le répertoire «
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../i686-linux-gnu/include » est
ignoré car inexistant
la recherche pour #include "..." débute ici :
la recherche pour #include <...> débute ici:
 /usr/lib/gcc/i686-linux-gnu/4.6.1/finclude
 /usr/lib/gcc/i686-linux-gnu/4.6.1/include
 /usr/local/include
 /usr/lib/gcc/i686-linux-gnu/4.6.1/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
Fin de la liste de recherche.
GNU Fortran (Ubuntu/Linaro 4.6.1-9ubuntu3) version 4.6.1 (i686-linux-gnu)
    compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
heuristiques GGC: --param ggc-min-expand=81 --param ggc-min-heapsize=95876
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 as --32 -o prog_stat.o prog_stat.s
Lecture des spécification à partir de
/usr/lib/gcc/i686-linux-gnu/4.6.1/libgfortran.spec
renommé les specs lib à liborig
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=i686'
COMPILER_PATH=/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-linux-gnu/4.6.1/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-Wall' '-Wextra' '-shared-libgcc'
'-mtune=generic' '-march=i686'
 /usr/lib/gcc/i686-linux-gnu/4.6.1/collect2 --build-id --no-add-needed
--as-needed --eh-frame-hdr -m elf_i386 --hash-style=gnu -dynamic-linker
/lib/ld-linux.so.2 -z relro
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/crt1.o
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/crti.o
/usr/lib/gcc/i686-linux-gnu/4.6.1/crtbegin.o
-L/usr/lib/gcc/i686-linux-gnu/4.6.1
-L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu
-L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../../lib -L/lib/i386-linux-gnu
-L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib
-L/usr/lib/gcc/i686-linux-gnu/4.6.1/../../.. prog_stat.o -lgfortran -lm -lgcc_s
-lgcc -lquadmath -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc
/usr/lib/gcc/i686-linux-gnu/4.6.1/crtend.o
/usr/lib/gcc/i686-linux-gnu/4.6.1/../../../i386-linux-gnu/crtn.o

[Bug fortran/51267] loop optimization error using LOC function

[kargl at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org 2011-11-22 15:40:43 UTC ---
(In reply to comment #0)
> Created attachment 25880 [details]
> simple source file
> 
> The small program attached fails using gfortran 4.6.1 (ubuntu oneiric built)
> using -O1 optimization level or higher (ok at -O0).
> It succeeds with gfortran 4.5.4 at all -O levels.
> 
> It ends by printing a boolean value : T if the test is ok, F else.
> 
> $ gfortran-4.5 -O1 -Wall -Wextra bug46_stat.f ; ./a.out
>  tab(           1 )=          -1
>  tab(           2 )=          -1
>  tab(           3 )=          -1
>  tab(           4 )=          -1
>  tab(           5 )=          -1
>  tab(           6 )=          -1
>  T
> 
> $ gfortran-4.6 -O1 -Wall -Wextra bug46_stat.f ; ./a.out
>  tab(           1 )=   134520832
>  tab(           2 )=    10813028
>  tab(           3 )=          -1
>  tab(           4 )=           0
>  tab(           5 )=    10870894
>  tab(           6 )=          -1
>  F
> 
> 
> Ouput with '-v' : 

Have you considered compiling the code with -fcheck=all?
It shows that you have an array reference issue.

troutmask:sgk[206] gfc4x -o z -fcheck=all -O bug46_stat.f
troutmask:sgk[207] ./z
At line 10 of file bug46_stat.f
Fortran runtime error: Index '-7' of dimension 1 of array 'ius' below lower
bound of 1

[Bug fortran/51267] loop optimization error using LOC function

[priv123 at hotmail dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

--- Comment #2 from Mathieu <priv123 at hotmail dot fr> 2011-11-22 20:22:15 UTC ---
Sure, and we are especially fans of -fbound-checks but we can not use it on
half of the code because of this usage.

For the story :
{
I reproduced here with this small code a part of the 1.e6 lines of our code
(see www.code-aster.org for more interest). It's 20 years old but it's always
evolving every week.

This usage (with an array allocated elsewhere and used in read/write using an
offset computed by LOC) allowed to simulate dynamic allocations and out-of-core
memory management in f77.
So if we are working to use current allocation management it requires to change
a lot of lines of code and the refactoring will be done part by part...
}

And just try this, it works :
c      do 12 i=1,3*n
c        ius(iad+i) = -1
c 12   continue
but not the unrolled loop.

That's why I think that the optimizer fails on that loop (and probably only
when the array of dimension(1)).

Do you know what does change between 4.5 and 4.6 that can explain the
difference of behavior ?
Any option to tune the behavior ?

Thx

[Bug fortran/51267] loop optimization error using LOC function

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-11-22 20:56:43 UTC ---
According my archived builds
r165415 (20101013) gives the result you expect
r165758 (20101021) does not.

> Any option to tune the behavior ?

-fno-tree-ds seems to do the trick: from the C manual

http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

> -ftree-dce
> Perform dead code elimination (DCE) on trees. This flag is enabled by default at -O and higher.

[Bug fortran/51267] loop optimization error using LOC function

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-11-22 21:03:51 UTC ---
> -fno-tree-ds seems to do the trick:

sorry, it is -fno-tree-dse and

> -ftree-dse
> Perform dead store elimination (DSE) on trees. A dead store is a store into a memory location 
> which will later be overwritten by another store without any intervening loads. 
> In this case the earlier store can be deleted. This flag is enabled by default at -O and higher. 

(it makes more sense;-).

[Bug fortran/51267] loop optimization error using LOC function

[priv123 at hotmail dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

--- Comment #5 from Mathieu <priv123 at hotmail dot fr> 2011-11-23 09:33:37 UTC ---
> -fno-tree-ds seems to do the trick: from the C manual

with -fno-tree-dse it works as I expect. Thanks.


Because reading the manual I didn't see this option (or more exactly I didn't
understand it should do the job), I tried to disable an option one by one.

So I get the enabled options enabled between -O0 and -O1 using : gfortran -Q
-O1 --help=optimizers
But using this command line :

gfortran -O0 -fcombine-stack-adjustments -fcompare-elim -fcprop-registers
-fdefer-pop -fforward-propagate -fguess-branch-probability -fif-conversion
-fif-conversion2 -fipa-profile -fipa-pure-const -fipa-reference
-fmerge-constants -fsplit-wide-types -ftree-bit-ccp -ftree-ccp -ftree-ch
-ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse
-ftree-fre -ftree-sink -ftree-sra -ftree-ter -Wall -Wextra xxxxx.F

it worked :-(
Does anybody know why ?




PS : I can mark this issue as RESOLVED and open a new one if you mean my
question is out-of-scope.

[Bug fortran/51267] loop optimization error using LOC function

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-11-23 17:56:17 UTC ---
On Wed, Nov 23, 2011 at 09:33:37AM +0000, priv123 at hotmail dot fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267
> 
> > -fno-tree-ds seems to do the trick: from the C manual
> 
> with -fno-tree-dse it works as I expect. Thanks.
> 

This does not "fix" the problem.  (Note, I initialized
tab=42 and ius=1; otherwise, you reference an undefined
variables.)

troutmask:sgk[209] gfc4x -o z bug46_stat.f && ./z
tab(1)=-1
tab(2)=-1
tab(3)=-1
tab(4)=-1
tab(5)=-1
tab(6)=-1
 T

troutmask:sgk[210] gfc4x -o z bug46_stat.f -O -fno-tree-dse && ./z
tab(1)=-1
tab(2)=42
tab(3)=42
tab(4)=-1
tab(5)=42
tab(6)=42
 F

trutmask:sgk[212] gfc4x -o z bug46_stat.f -ftree-dse && ./z
tab(1)=-1
tab(2)=-1
tab(3)=-1
tab(4)=-1
tab(5)=-1
tab(6)=-1
 T

[Bug fortran/51267] loop optimization error using LOC function

[priv123 at hotmail dot fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

--- Comment #7 from Mathieu <priv123 at hotmail dot fr> 2011-11-25 09:37:15 UTC ---
(In reply to comment #6)
> This does not "fix" the problem.  (Note, I initialized
> tab=42 and ius=1; otherwise, you reference an undefined
> variables.)

Steve, I can't reproduce that you obtained.
Even if I initialized tab & ius differently.

> you reference an undefined variables.

No, tab should be filled through ius(offset).


Did you use a newer built ?
What changes to the code ?

Thanks

[Bug fortran/51267] loop optimization error using LOC function

[sgk at troutmask dot apl.washington.edu]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

--- Comment #8 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2011-11-25 15:58:34 UTC ---
On Fri, Nov 25, 2011 at 09:37:15AM +0000, priv123 at hotmail dot fr wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267
> 
> --- Comment #7 from Mathieu <priv123 at hotmail dot fr> 2011-11-25 09:37:15 UTC ---
> (In reply to comment #6)
> > This does not "fix" the problem.  (Note, I initialized
> > tab=42 and ius=1; otherwise, you reference an undefined
> > variables.)
> 
> Steve, I can't reproduce that you obtained.
> Even if I initialized tab & ius differently.
> 
> > you reference an undefined variables.
> 
> No, tab should be filled through ius(offset).
> 

Not from the point of view of Fortran.

> Did you use a newer built ?

gcc version 4.7.0 20111122 (experimental) (GCC) 

> What changes to the code ?

I suspect that the difference if due to differences in
the target.  My results are for x86_64-*-freebsd.

[Bug fortran/51267] loop optimization error using LOC function

[godeezy at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

Oliver <godeezy at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |godeezy at gmail dot com

--- Comment #9 from Oliver <godeezy at gmail dot com> 2012-04-25 14:37:08 UTC ---
Is there any progress with this? The issue persists with gcc 4.7.0 final and
the workaround with -fno-tree-dse stopped working.

[Bug fortran/51267] loop optimization error using LOC function

[tkoenig at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |tkoenig at gcc dot gnu.org
         Resolution|                            |INVALID

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2012-05-01 09:45:54 UTC ---
(In reply to comment #9)
> Is there any progress with this? The issue persists with gcc 4.7.0 final and
> the workaround with -fno-tree-dse stopped working.

The test case violates the standard.  The compiler knows that the array
tab cannot be accessed in a legal way, and that the stores into array
ius are not used later.  Therefore, they are removed.

This part of Fortran semantics allows a lot of optimizations, and we
will not make other programs slower to accommodate this non-standard
usage. 

So, your best bet is to simulate dynamic memory some other way, for
example by handing out parts of a COMMON block, or use F90+ memory
management.

Your second best bet is to compile all relevant code parts with -O0,
and keep your fingers crossed that it keeps on working.  This is likely,
but not guaranteed.

Closing as invalid.

[Bug fortran/51267] loop optimization error using LOC function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #11 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-02 12:21:45 UTC ---
(In reply to comment #9)
> Is there any progress with this? The issue persists with gcc 4.7.0 final and
> the workaround with -fno-tree-dse stopped working.

As post script:

The issue also exists with other compilers: ifort 12.1 does the same
optimization with -O1 as gfortran; as does pathf95 (with -O2).

You could try to mark the variables as VOLATILE - at least for the test case,
   VOLATILE :: tab, ius
solves the issue for gfortran and ifort. Thomas mentioned -O0, which is also an
alternative.

However, the only true solution is to fix the code. (I realize that it won't be
easy for a large code like Code Aster.)

Re: [Bug fortran/51267] loop optimization error using LOC function

[Jan Hubicka]

I am surprised that this does not happen already at PRE :)
Without volatile attribute there is really nothing that prevents GCC from doing this optimization
and unfortunately I don't think we provide way to prevent it without this big hammer.

We have fpcr register defined for the control word that is accepted in clobber list, but there
is no way to express use of this I think.

Honza

[Bug fortran/51267] loop optimization error using LOC function

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

--- Comment #12 from Jan Hubicka <hubicka at ucw dot cz> 2012-05-02 13:05:42 UTC ---
I am surprised that this does not happen already at PRE :)
Without volatile attribute there is really nothing that prevents GCC from doing
this optimization
and unfortunately I don't think we provide way to prevent it without this big
hammer.

We have fpcr register defined for the control word that is accepted in clobber
list, but there
is no way to express use of this I think.

Honza

[Bug fortran/51267] loop optimization error using LOC function

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51267

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alain.hebert at polymtl dot
                   |                            |ca

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-07-31 17:00:37 UTC ---
*** Bug 54141 has been marked as a duplicate of this bug. ***