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: About the is_gimple_min_invariant predicate

> It is a formal predicate of the GIMPLE grammar.  But there is an
> inconsistency now.  I don't think we want to allow min-invariant as
> ARRAY_REF indexes because this would allow things like
> 	&a[&b[3]]
> which is too gross for words.  So, the grammar should be updated to
> include invariant addresses in 'val',

Like so?

Index: doc/tree-ssa.texi
--- doc/tree-ssa.texi   (revision 126300)
+++ doc/tree-ssa.texi   (working copy)
@@ -1,4 +1,4 @@
-@c Copyright (c) 2004, 2005 Free Software Foundation, Inc.
+@c Copyright (c) 2004, 2005, 2007 Free Software Foundation, Inc.
 @c Free Software Foundation, Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
@@ -680,7 +680,7 @@ void f()
    bitfieldref  : BIT_FIELD_REF
                         op0 -> inner-compref
                         op1 -> CONST
-                        op2 -> var
+                        op2 -> val

    compref      : inner-compref
                 | TARGET_MEM_REF
@@ -718,6 +718,8 @@ void f()
                         op1 -> val

    val          : ID
+                | invariant ADDR_EXPR
+                        op0 -> addr-expr-arg
                 | CONST

    rhs          : lhs

> but it should have a new rule so that no invariant addresses are allowed as
> array indices. 

This would require more substantial changes in the gimplifier than what is 
required to fix the is_gimple_min_invariant problem.  Can't we live with it?

Eric Botcazou

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