This is the mail archive of the gcc@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] |
On Wed, 13 Aug 2003 15:53:41 -0400, Daniel Berlin <dberlin@dberlin.org> wrote:
I've been seeing expressions like T.2 = (char * const &)&<UVbbd0>
generated by the C++ FE lately (compiling string-inst.cc on darwin, for
instance).
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?
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?
k = q + b t = k + 9 a[t] = blah + blah because 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)?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |