Re: [patch] Re: GCC 2.95 Solaris7 i86pc compilation fail with -g generates internal compiler error

[Jeffrey A Law <law at cygnus dot com>]

Did this issue ever get resolved.  I've got a flurry of mail, but I couldn't
find a resolution....


  In message <orwvv0zz4i.fsf@cupuacu.lsd.dcc.unicamp.br>you write:
  > On Aug 12, 1999, Mark Mitchell <mark@codesourcery.com> wrote:
  > 
  > > First, I see that this patch appears now to be in the tree.  Did
  > > someone else approve the patch, despite my objections?
  > 
  > Of course, I wouldn't have installed it without permission.  Jason
  > approved one week ago, just after I posted the revised version, after
  > rth's comments, and you raised your objection only two days ago.
  > 
  > > It's in general wrong for convert to be operating on possibly
  > > template-containing things.  Such things should not be converted.  In
  > > this case, you will probably get away with, as long as we never change
  > > convert to peek inside an expression in any way.
  > 
  > Or at least to never do it if the expression already has the required
  > type.
  > 
  > > And, I'm obviously not being clear in my question.  You answered "why
  > > does dwarfout crash", not "how does this type get to dwarfout".
  > 
  > All I know is that tsubst, case INTEGER_TYPE, would create an integer
  > type without setting its PRECISION.  Then, when that type got to
  > dwarfout.c:fundamental_type_code(), it would have TYPE_PRECISION == 0,
  > so it would crash.
  > 
  > > You're bypassing these checks.
  > 
  > I see.  AFAIR, tsubst wouldn't happen again for g++.oliva/dwarf1.C.
  > Here it is, for the convenience of the audience:
  > 
  > template <class T = void>
  > struct foo {
  >   static const int ELEMENTS = 1;
  >   int bar[ELEMENTS];
  > };
  > foo<> bar;
  > 
  > AFAIR, it would also crash if ELEMENTS was a global constant.
  > 
  > > The bug is either:
  > >   o We shouldn't be in the conditional in this case.
  > >   o We're not re-tsubst'ing into the type later.
  > 
  > I vote for #2 :-)
  > 
  > > Your fix, even if not actually dangerous, is almost certainly not the
  > > real fix.
  > 
  > Agreed.
  > 
  > > I've already asked twice, but I'll try to ask more clearly:
  > 
  > I expected you'd get the answers from the testcase, which I already
  > mentioned twice :-)  But I'll try to answer it completely this time,
  > based on my memories of the debugging session.
  > 
  > >   o What is MAX at this point?
  > 
  > AFAIR, it was just a MINUS_EXPR of the ELEMENT data member and the
  > constant 1.
  > 
  > >   o Why does this type reach dwarfout?
  > 
  > It seems that whatever tsubst returns remains unchanged, but I can't
  > promise.
  > 
  > >     What are we doing when we get to this tsubst call?
  > 
  > It enters the (processing_template_decl || TREE_CODE ...) test and
  > returns the new index type.
  > 
  > >     Are we performing a complete initialization?
  > 
  > I don't recall having found any further invocations of tsubst, but I
  > may be wrong, since I did not expect it to happen then.  Anyway, I
  > won't be able to pursue this issue today, so I'd appreciate if you (or
  > anybody else) could try your suggestion and test it with -gdwarf.
  > Hopefully, it will fix a couple of other Solaris/x86 bug reports we've
  > seen.  
  > 
  > -- 
  > Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
  > oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
  > oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
  > ** I may forward mail about projects to mailing lists; please use them
  >