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

[Mark Mitchell <mark@codesourcery.com>]

>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

    >> I still want to know why this type is getting through to
    >> dwarfout.c.

    Alexandre> Because tsubst won't take care of defining a PRECISION
    Alexandre> for the array type.

First, I see that this patch appears now to be in the tree.  Did
someone else approve the patch, despite my objections?  (There are
certainly people allowed to do so; I just didn't see the message.)

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.

And, I'm obviously not being clear in my question.  You answered "why
does dwarfout crash", not "how does this type get to dwarfout".  The
intent of this conditional:

	if (processing_template_decl 
	    /* When providing explicit arguments to a template
	       function, but leaving some arguments for subsequent
	       deduction, MAX may be template-dependent even if we're
	       not PROCESSING_TEMPLATE_DECL.  */
	    || TREE_CODE (max) != INTEGER_CST)

is to handle the case where MAX is not yet a fully resolved integer,
or where we're inside a template.  In those cases, we should only be
building a type that we will later tsubst into some more.  Look what
happens next:

	if (integer_zerop (omax))
	  {
	    /* Still allow an explicit array of size zero.  */
	    if (pedantic)
	      pedwarn ("creating array with size zero");
	  }
	else if (integer_zerop (max) || INT_CST_LT (max, integer_zero_node))
	  {
	    /* [temp.deduct]

	       Type deduction may fail for any of the following
	       reasons:  

		 Attempting to create an array with a size that is
		 zero or negative.  */
	    if (complain)
	      cp_error ("creating array with size `%E'", max);

	    return error_mark_node;
	  }

You're bypassing these checks.  That's only OK if the checks will be
done later, when the tsubst'ing happens again.  I don't think that the
dwarf output routines should see anything from inside a template, or a
partial instantiation, and that's what the type you're playing with
is supposed to be.  

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.

Your fix, even if not actually dangerous, is almost certainly not the
real fix.

I've already asked twice, but I'll try to ask more clearly:

  o What is MAX at this point?

  o Why does this type reach dwarfout?  What are we doing when we
    get to this tsubst call?  Are we performing a complete
    initialization? 

Looking at the test-case and the code, my guess is that we should do:

  if (TREE_READONLY_DECL_P (max))
    max = decl_constant_value (max);

and back out your patch.  Does that fix the bug?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com