This is the mail archive of the gcc-patches@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]

Re: [C++ PATCH] (regression) Set TREE_CONSTANT for STATIC_EXPR andCAST_EXPR


Mark Mitchell <mark@codesourcery.com> wrote:

>> Completly agreed.  Those semantics restrictions should be checked only
>> at full instantiation points.
>
> Au contraire!
>
> They can be checked whenever we want to check them, and early is good.
>
> We need to move more in this direction so that we can do dependency
> analysis correctly; we've got to stop just saying "we're in a template
> so put everything off until instantiation time."

And what do you think of my TREE_CONSTANT patch then? I originally tried to
do what you are saying here, that is modifying build_c_cast() and
build_static_cast() so that they would build a STATIC_CAST_EXPR/CAST_EXPR
*only* if we're parsing a template *and* the type/expression are dependent.
This fixed the testcase (static const int a = static_cast<int>(123); static
const int b = a;), but it breaks code like this:

template <class T>
void Foo(void)
{
   T a[2];
   if (static_cast<A*>(static_cast<B*>(&a[1])))
      ;
}

because:

- the inner static_cast is detected as dependent (its expression is
type-dependent), so it's built as STATIC_CAST_EXPR
- the outer static_cast is detected as non-dependent (the type it's casting
to is not dependent, and its expression, the STATIC_CAST_EXPR, isn't
type-dependent, nor value-dependent), so it's folded to a NOP_EXPR (assuming
A is a valid non-virtual base for B in a single-inheritance graph).
- when tsubt-ing, tsubst_copy_and_build finds a NOP_EXPR, and falls down to
a tsubst_copy. tsubst_copy then calls itself recorsively, so the inner
STATIC_CAST_EXPR is tsubst'd without calling build_static_cast(). Thus, the
instantiation pass fails getting rid of the STATIC_CAST_EXPR tree
- the compiler ICEs later because it finds a STATIC_CAST_EXPR it's not
expecting.

Since I know too little to fix such a problem, I decided to go for the
shortest path (Nathan suggested me this). Instead of trying to get rid of
non-dependent [STATIC_]CAST_EXPR, I just propagate the TREE_CONSTANT flag to
make cc1plus happy with the original testcase.

Giovanni Bajo


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