This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tuples] Convert type checking code to use tuples
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Diego Novillo" <dnovillo at google dot com>
- Cc: gcc-patches at gcc dot gnu dot org, "Aldy Hernandez" <aldyh at redhat dot com>, "Christopher Matthews" <chrismatthews at google dot com>, "Ben Elliston" <bje at au1 dot ibm dot com>
- Date: Thu, 30 Aug 2007 12:34:52 +0200
- Subject: Re: [tuples] Convert type checking code to use tuples
- References: <b798aad50708300323x105a96e2obffd53431c745360@mail.gmail.com>
On 8/30/07, Diego Novillo <dnovillo@google.com> wrote:
> This patch from Chris converts the type checking code to use tuples.
> This required a few changes in the checking of GIMPLE_ASSIGN. Since
> the RHS is not an expression tree anymore, the checker needs to
> explicitly check types of each operand against what it's expected from
> the actual operation code (whereas before, checking TREE_TYPE (rhs)
> was sufficient).
>
> This gives us better control over the check, but it also means that we
> have to check several special cases.
>
> The verifier found two problems in the gimplifier that I'm fixing in a
> subsequent patch.
You changed what are valid types in operations. For example we now have
+ if (rhs_code == NOP_EXPR
+ || rhs_code == CONVERT_EXPR
+ || rhs_code == FLOAT_EXPR
+ || rhs_code == FIX_TRUNC_EXPR
+ || rhs_code == FIXED_CONVERT_EXPR)
{
- /* OpenMP directives are validated by the FE and never operated
- on by the optimizers. Furthermore, OMP_FOR may contain
- non-gimple expressions when the main index variable has had
- its address taken. This does not affect the loop itself
- because the header of an OMP_FOR is merely used to determine
- how to setup the parallel iteration. */
+ /* Type casts are OK. */
return false;
but that is certainly not ok. For example FIX_TRUNC_EXPR with an
integral argument or the other restrictions that were imposed before.
It would be nice if you wouldn't do such semantic changes while doing
the tuple conversion as they are quite possibly going to be "lost" in the
noise when merging the tuples work.
Thanks,
Richard.