This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[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
- From: "sje at cup dot hp dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 15 Apr 2010 17:10:40 -0000
- Subject: [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
- References: <bug-42169-276@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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: <unnamed-unsigned:32> D.762;
x.f90.003t.original: D.762 = (<unnamed-unsigned:32>) 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