This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: tidy some gimplifcation unsharing
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: 28 May 2004 06:45:53 -0300
- Subject: Re: tidy some gimplifcation unsharing
- Organization: Red Hat Global Engineering Services Compiler Team
- References: <20040521220523.GA11618@redhat.com>
On May 21, 2004, Richard Henderson <rth@redhat.com> wrote:
> The VA_ARG_EXPR thing is handled during gimplification elsewhere.
But that's too late. We may have already expanded statements assuming
variables referenced within VA_ARG_EXPRs are not volatile, in which
case the stmts will fail gimple verification later. This broke the
build of uClibc for frv-uclinux.
> Don't mark VA_ARG_EXPRs volatile here.
Ok to revert this bit?
Actually... There should be a comment explaining why it's there, to
avoid having someone else make the same mistake. Ok to install this,
if it bootstraps? I'll post a proper patch, with a ChangeLog entry,
when I'm done testing.
What I'm not sure is whether it would be reasonable to remove the
equivalent call from gimplify_expr(). What do you think?
While at that... Is it really the case that VA_ARG_EXPR can take
arbitrarily complex lvalue expressions? Consider, for example,
foo->bar[baz]->saved_va_list. Shouldn't we even attempt to gimplify the
expression as an lvalue, and, while at that, do so before marking the
decls found in the expression? I don't think we should be changing
global decls just because they happen to be mentioned in the argument
to va_arg. Am I missing anything?
--- gimplify.c.~2.6.~ 2004-05-28 01:36:45.000000000 -0300
+++ gimplify.c 2004-05-28 06:21:16.000000000 -0300
@@ -665,7 +665,19 @@ copy_if_shared_r (tree *tp, int *walk_su
/* Otherwise, mark the tree as visited and keep looking. */
else
- TREE_VISITED (t) = 1;
+ {
+ TREE_VISITED (t) = 1;
+ if (TREE_CODE (*tp) == VA_ARG_EXPR)
+ {
+ /* Mark any _DECL inside the operand as volatile to avoid
+ the optimizers messing around with it. We have to do this
+ early, otherwise we might mark a variable as volatile
+ after we gimplify other statements that use the variable
+ assuming it's not volatile. */
+ walk_tree (&TREE_OPERAND (*tp, 0), mark_decls_volatile_r,
+ NULL, NULL);
+ }
+ }
return NULL_TREE;
}
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}