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: [tree-ssa]: Invalid GIMPLE generated by C++ front end

On Wednesday, August 13, 2003, at 4:52 PM, Jason Merrill wrote:

On Wed, 13 Aug 2003 15:53:41 -0400, Daniel Berlin <> wrote:

I've been seeing expressions like T.2 = (char * const &)&<UVbbd0>
generated by the C++ FE lately (compiling on darwin, for

Are these actually valid GIMPLE?

No. I ran into a similar crash recently; the problem turned out to be with
the inliner inserting nops during &* elimination. I've attached a patch
below. Does it fix your bug?

Bootstrapping now.

Going by the grammar, they aren't, and they are causing PTA to miss some
variables because they fail is_gimple_modify_expr.

Incidentally, I'm in the process of converting all of the gimplification
predicates to only check the tree code in most cases, since that's all I
care about during gimplification. The underlying nodes will already have
been massaged into the right form by recursive gimplification.

But your comment brings up the possibility that other passes will want to
be able to check whether or not a transformation leaves the code in gimple
form. Is this what you need?

Yup. But not for PTA.
Forward, substitution, for instance, can only substitute when the resulting expression is still in GIMPLE form.

IE forward subst takes something like

k = q + 3
t = k + 9
a[t] = blah + blah
and makes it
a[q + 12] = blah + blah
(It's a loop pre-transformation to make dependence analysis and whatnot easier)
We can't do this if we had something like:

k = q + b
t = k + 9
a[t] = blah + blah
a[q + b + 9] = blah + blah
is not valid GIMPLE.

If so, would calling back into gimplify_expr
be a reasonable alternative (if it worked)?

Well, in this case, no, because we just don't want to perform the transform at all if we can't make it come out as a GIMPLE expression. If we re-gimplified, we'd end up with the same thing we started with!

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