[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-21 Thread danglin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

John David Anglin  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #26 from John David Anglin  2010-10-21 
23:07:28 UTC ---
Fixed.


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-20 Thread vmakarov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #25 from Vladimir Makarov  2010-10-20 
14:06:11 UTC ---
Author: vmakarov
Date: Wed Oct 20 14:06:08 2010
New Revision: 165724

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165724
Log:
2010-10-20  Vladimir Makarov  

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
branches/gcc-4_4-branch/gcc/ChangeLog
branches/gcc-4_4-branch/gcc/ira-emit.c


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-20 Thread vmakarov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #24 from Vladimir Makarov  2010-10-20 
14:05:25 UTC ---
Author: vmakarov
Date: Wed Oct 20 14:05:21 2010
New Revision: 165723

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165723
Log:
2010-10-20  Vladimir Makarov  

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
branches/gcc-4_5-branch/gcc/ChangeLog
branches/gcc-4_5-branch/gcc/ira-emit.c


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-20 Thread vmakarov at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #23 from Vladimir Makarov  2010-10-20 
13:51:37 UTC ---
Author: vmakarov
Date: Wed Oct 20 13:51:31 2010
New Revision: 165722

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=165722
Log:
2010-10-20  Vladimir Makarov  

PR fortran/42169
* ira-emit.c (store_can_be_removed_p): Return false instead of
gcc_unreachable.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-emit.c


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-19 Thread vmakarov at redhat dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at redhat dot com

--- Comment #22 from Vladimir Makarov  2010-10-20 
03:03:53 UTC ---
Function store_can_be_removed_p was written in assumption that the store is on
a loop exit.  Apparently it is not true.  In this case, it was actually a loop
entry from 4 to 5 in loop tree:

0->1->2->3->4->5
|
 -->6->7

There should be some rare combinations of conditions (one is that pseudo is not
changed in whole program) to achieve gcc_unreachable for the loop entry. 
Therefore it is hard to reproduce.

There is a very simple solution which is to return false (preventing this
optimization) instead of gcc_unreachable (that is a loop entry case).

I'll send a patch soon.


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-19 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #21 from Richard Guenther  2010-10-19 
10:55:08 UTC ---
(In reply to comment #20)
> Not really, there are about 300 lines of new code (mostly in a new routine).
> It might be that only the change in can_reassociate_p is needed to fix this
> bug.
> That would be a pretty easy backport and I verified that it fixes the 
> testcase,
> I haven't done a complete run with the change though.

Just backporting that change will cause quite some regressions.  Note that
I think it can't be a real fix for the ICE - it'll only paper over it.


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-18 Thread sje at cup dot hp.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #20 from Steve Ellcey  2010-10-18 17:54:42 
UTC ---
Not really, there are about 300 lines of new code (mostly in a new routine).
It might be that only the change in can_reassociate_p is needed to fix this
bug.
That would be a pretty easy backport and I verified that it fixes the testcase,
I haven't done a complete run with the change though.


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-18 Thread dave at hiauly1 dot hia.nrc.ca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #19 from dave at hiauly1 dot hia.nrc.ca 2010-10-18 17:27:04 UTC ---
> It looks like this was fixed (for hppa at least) in r163190.
> 
> 2010-08-12  Richard Guenther  
> 
> PR tree-optimization/45232
> * tree-ssa-reassoc.c (can_reassociate_p): Disable re-association
> for types with undefined overflow.
> (reassociate_bb): Allow re-associating of bit and min/max
> operations for types with undefined overflow.
> * tree-ssa-forwprop.c (associate_plusminus): New function.
> (tree_ssa_forward_propagate_single_use_vars): Call it.

Is it easy to backport?

Dave


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-18 Thread sje at cup dot hp.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #18 from Steve Ellcey  2010-10-18 16:55:32 
UTC ---
It looks like this was fixed (for hppa at least) in r163190.

2010-08-12  Richard Guenther  

PR tree-optimization/45232
* tree-ssa-reassoc.c (can_reassociate_p): Disable re-association
for types with undefined overflow.
(reassociate_bb): Allow re-associating of bit and min/max
operations for types with undefined overflow.
* tree-ssa-forwprop.c (associate_plusminus): New function.
(tree_ssa_forward_propagate_single_use_vars): Call it.


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-18 Thread sje at cup dot hp.com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #17 from Steve Ellcey  2010-10-18 15:51:52 
UTC ---
(In reply to comment #16)
> Based on my posted test results for hppa2.0-hp-hpux11.11, this PR was
> fixed on the trunk between r163182 and r163254.
> 
> Need to find the change.

My nightly testing shows it fixed by r163218, I'll see if I can find the
exact version number.


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-17 Thread danglin at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

--- Comment #16 from John David Anglin  2010-10-17 
21:01:27 UTC ---
Based on my posted test results for hppa2.0-hp-hpux11.11, this PR was
fixed on the trunk between r163182 and r163254.

Need to find the change.


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-10-01 Thread jakub at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|4.4.5   |4.4.6


[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-09-21 Thread burnus at gcc dot gnu dot org


--- Comment #15 from burnus at gcc dot gnu dot org  2010-09-21 09:20 ---
Any idea what could be done from the gfortran side? Without being able to
reproduce it, it is a bit difficult to debug :-(


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-06-28 Thread danglin at gcc dot gnu dot org


--- Comment #14 from danglin at gcc dot gnu dot org  2010-06-28 19:31 
---
I still see it as of 161474 (both head and 4.5).


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-06-11 Thread sje at cup dot hp dot com


--- Comment #13 from sje at cup dot hp dot com  2010-06-11 20:19 ---
On hppa2.0w-hp-hpux11.11, I don't see the testsuite failure after 158397.


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-06-11 Thread hp at gcc dot gnu dot org


--- Comment #12 from hp at gcc dot gnu dot org  2010-06-11 20:07 ---
(In reply to comment #11)
> (In reply to comment #10)
> > Now (with r160560) appearing for cris-elf too!
> 
> Forgot to mention that it last worked for cris-elf with r160547.

Last known appearance r160602, gone again at r160612.


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-06-10 Thread hp at gcc dot gnu dot org


--- Comment #11 from hp at gcc dot gnu dot org  2010-06-10 21:02 ---
(In reply to comment #10)
> Now (with r160560) appearing for cris-elf too!

Forgot to mention that it last worked for cris-elf with r160547.


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-06-10 Thread hp at gcc dot gnu dot org


--- Comment #10 from hp at gcc dot gnu dot org  2010-06-10 21:00 ---
Now (with r160560) appearing for cris-elf too!


-- 

hp at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||hp at gcc dot gnu dot org


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-04-30 Thread jakub at gcc dot gnu dot org


-- 

jakub at gcc dot gnu dot org changed:

   What|Removed |Added

   Target Milestone|4.4.4   |4.4.5


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-04-16 Thread dominiq at lps dot ens dot fr


--- Comment #9 from dominiq at lps dot ens dot fr  2010-04-16 20:15 ---
When compiled with -O2 -Wuninitialized, the reduced test of comment #3 gives

...
pr42169.f90: In function 'moment':
pr42169.f90:15:0: warning: 'lx' may be used uninitialized in this function
pr42169.f90:16:0: warning: 'lx1' may be used uninitialized in this function

(without ICE on x86_64-apple-darwin10).


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-04-16 Thread sje at cup dot hp dot com


--- Comment #8 from sje at cup dot hp dot com  2010-04-16 19:54 ---
I think the problem is related to the fact that IRA is trying to figure out if
the store of lx1 can be eliminated and lx1 may be uninitialized.  The only
place lx1 is set is in an if statement in a loop.  If we don't execute the if
statement then lx1 is never set and this may be what IRA is complaining about.


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-04-15 Thread sje at cup dot hp dot com


--- Comment #7 from sje at cup dot hp dot com  2010-04-15 23:47 ---
Since the failure requires -O1 as well as -fbounds-check I tried turning off
various -O1 optimizations.  I could turn off everything (and still get the bug)
except if I use -fno-tree-dominator-opts or -fno-guess-branch-probability.
If I use either of these flags the bug does not happen.  I think something is
happening related to the fact that _gfortran_runtime_error_at is marked as
'NORETURN' that is causing a bad optimization.  It may be related to making
registers as REG_DEAD but I haven't found a place where I think this marking
is actually wrong yet.


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-04-15 Thread sje at cup dot hp dot com


--- Comment #6 from sje at cup dot hp dot com  2010-04-15 17:10 ---
I tried comparing the tree's between hppa2.0w-hp-hpux11.11, where I get the bug
and ia64-hp-hpux11.23, where I do not see the bug and I didn't see any real
differences in the trees, just differences in the names of generated variables
(D.1056 vs. D.1077, etc).  I used my cutdown test case, testcase.f90, which is
the smallest test case I was able to create.  The unnamed-unsigned variables I
see are 32 bits and not 64 bits, but the odd thing that I see (on both pa and
ia64)
is:

$ grep D.762 x*.f90.*
x.f90.003t.original:   D.762;
x.f90.003t.original:D.762 = () size.6 * 8;

The variable is given a value but never used.  These 'unnamed-unsigned'
variables seem to disappear during the copyrename1 phase.  I think this value
is the size of the array, in this case the size of ncoset.  I guess the Fortran
front-end generates it in case it is needed but in this case it is never needed
and so gets optimized away.  I don't know if it is related to the problem at
all but I do wonder why it is 'unnamed-unsigned' and not given a real type
name.


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-04-14 Thread kargl at gcc dot gnu dot org


--- Comment #5 from kargl at gcc dot gnu dot org  2010-04-15 04:13 ---
(In reply to comment #4)
> An ice is an ice.  However, this is particularly nasty to me since it is 
> trying
> to use reals for index variables.
> 
> Have you tried to get this down to a single loop and get the ice?
> 
> In -fdump-tree-original I see this:
> 
>  D.1619;

I tried reproducing the problem on FreeBSD.  It appears, as
Steve stated, to be target specific.  We may need to compare
the output of -fdump-tree-all on hppa with a non-hppa target.

> What is this? an unsigned 64 bit integer?
> 


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-04-14 Thread jvdelisle at gcc dot gnu dot org


--- Comment #4 from jvdelisle at gcc dot gnu dot org  2010-04-15 00:17 
---
An ice is an ice.  However, this is particularly nasty to me since it is trying
to use reals for index variables.

Have you tried to get this down to a single loop and get the ice?

In -fdump-tree-original I see this:

 D.1619;

What is this? an unsigned 64 bit integer?


-- 


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



[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371

2010-04-14 Thread sje at cup dot hp dot com


-- 

sje at cup dot hp dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|middle-end  |fortran
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2010-04-14 21:56:44
   date||


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