This is the mail archive of the 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] Fix mangling of COMPOUND_EXPR

Nathan Sidwell <> wrote:

> Have you investigated why COMPOUND_EXPRs are different inside templates?
> It might be a hold over from the old parser which had issues with cast
> and abstract decls. It would be neater if you could fix it there.

It's because the parser constructs a list of expressions separated by comma
(any size) and then call build_x_compound_expr.

The logic behind build_x_compound_expr and build_compound_expr is to go
recursively through the list, lookup overloading of the comma operator,
check for some little semantic property and then build (bottom-up) a tree of
COMPOUND_EXPR, each one with only two operands (and the type of the second).

Now, since within templates we postpone everything to template
instantiation, the quickest and safest way to reuse these two build
functions is just to store the list built by the parser somewhere. Thus,
within templates, the list is stored within the first operand of
COMPOUND_EXPR; at tsubst time, the list gets tsubst'd and then
build_x_compound_expr is called on the resulting list.

If we want to avoid this, we should heavily modify the way the two build
functions work, and the way the parser calls them. Do you think it's worth
it? After all, there should be only a few points where we mess with
pre-tsubst'd trees in templates. Alternatively, we could introduce a
COMPOUND_EXPR2 for templates, which would probably let us check very quickly
where it is not handled (all those switches would fall to the default, that
probably aborts).

Giovanni Bajo

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