This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[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



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]