* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
@ 2011-11-22 15:48 ` kargl at gcc dot gnu.org
2011-11-22 20:55 ` priv123 at hotmail dot fr
` (11 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: kargl at gcc dot gnu.org @ 2011-11-22 15:48 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
2011-11-22 15:48 ` [Bug fortran/51267] " kargl at gcc dot gnu.org
@ 2011-11-22 20:55 ` priv123 at hotmail dot fr
2011-11-22 21:09 ` dominiq at lps dot ens.fr
` (10 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: priv123 at hotmail dot fr @ 2011-11-22 20:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
2011-11-22 15:48 ` [Bug fortran/51267] " kargl at gcc dot gnu.org
2011-11-22 20:55 ` priv123 at hotmail dot fr
@ 2011-11-22 21:09 ` dominiq at lps dot ens.fr
2011-11-22 21:34 ` dominiq at lps dot ens.fr
` (9 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-11-22 21:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (2 preceding siblings ...)
2011-11-22 21:09 ` dominiq at lps dot ens.fr
@ 2011-11-22 21:34 ` dominiq at lps dot ens.fr
2011-11-23 10:46 ` priv123 at hotmail dot fr
` (8 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-11-22 21:34 UTC (permalink / raw)
To: gcc-bugs
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;-).
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (3 preceding siblings ...)
2011-11-22 21:34 ` dominiq at lps dot ens.fr
@ 2011-11-23 10:46 ` priv123 at hotmail dot fr
2011-11-23 18:35 ` sgk at troutmask dot apl.washington.edu
` (7 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: priv123 at hotmail dot fr @ 2011-11-23 10:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (4 preceding siblings ...)
2011-11-23 10:46 ` priv123 at hotmail dot fr
@ 2011-11-23 18:35 ` sgk at troutmask dot apl.washington.edu
2011-11-25 10:01 ` priv123 at hotmail dot fr
` (6 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2011-11-23 18:35 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (5 preceding siblings ...)
2011-11-23 18:35 ` sgk at troutmask dot apl.washington.edu
@ 2011-11-25 10:01 ` priv123 at hotmail dot fr
2011-11-25 16:27 ` sgk at troutmask dot apl.washington.edu
` (5 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: priv123 at hotmail dot fr @ 2011-11-25 10:01 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (6 preceding siblings ...)
2011-11-25 10:01 ` priv123 at hotmail dot fr
@ 2011-11-25 16:27 ` sgk at troutmask dot apl.washington.edu
2012-04-25 14:37 ` godeezy at gmail dot com
` (4 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: sgk at troutmask dot apl.washington.edu @ 2011-11-25 16:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (7 preceding siblings ...)
2011-11-25 16:27 ` sgk at troutmask dot apl.washington.edu
@ 2012-04-25 14:37 ` godeezy at gmail dot com
2012-05-01 9:46 ` tkoenig at gcc dot gnu.org
` (3 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: godeezy at gmail dot com @ 2012-04-25 14:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (8 preceding siblings ...)
2012-04-25 14:37 ` godeezy at gmail dot com
@ 2012-05-01 9:46 ` tkoenig at gcc dot gnu.org
2012-05-02 12:22 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 15+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2012-05-01 9:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (9 preceding siblings ...)
2012-05-01 9:46 ` tkoenig at gcc dot gnu.org
@ 2012-05-02 12:22 ` burnus at gcc dot gnu.org
2012-05-02 13:05 ` Jan Hubicka
2012-05-02 13:06 ` hubicka at ucw dot cz
2012-07-31 17:02 ` dominiq at lps dot ens.fr
12 siblings, 1 reply; 15+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-02 12:22 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [Bug fortran/51267] loop optimization error using LOC function
2012-05-02 12:22 ` burnus at gcc dot gnu.org
@ 2012-05-02 13:05 ` Jan Hubicka
0 siblings, 0 replies; 15+ messages in thread
From: Jan Hubicka @ 2012-05-02 13:05 UTC (permalink / raw)
To: burnus at gcc dot gnu.org; +Cc: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (10 preceding siblings ...)
2012-05-02 12:22 ` burnus at gcc dot gnu.org
@ 2012-05-02 13:06 ` hubicka at ucw dot cz
2012-07-31 17:02 ` dominiq at lps dot ens.fr
12 siblings, 0 replies; 15+ messages in thread
From: hubicka at ucw dot cz @ 2012-05-02 13:06 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread* [Bug fortran/51267] loop optimization error using LOC function
2011-11-22 13:19 [Bug fortran/51267] New: loop optimization error using LOC function priv123 at hotmail dot fr
` (11 preceding siblings ...)
2012-05-02 13:06 ` hubicka at ucw dot cz
@ 2012-07-31 17:02 ` dominiq at lps dot ens.fr
12 siblings, 0 replies; 15+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-07-31 17:02 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 15+ messages in thread