This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Re: GCC 2.95 Solaris7 i86pc compilation fail with -g generates internal compiler error
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