From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-86000-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6809 invoked by alias); 19 Nov 2003 19:01:54 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 6779 invoked from network); 19 Nov 2003 19:01:53 -0000
Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123)
  by sources.redhat.com with SMTP; 19 Nov 2003 19:01:53 -0000
Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018)
	id 7CB264C0004; Wed, 19 Nov 2003 20:01:52 +0100 (CET)
Date: Wed, 19 Nov 2003 19:09:00 -0000
From: Jan Hubicka <hubicka@ucw.cz>
To: Richard Henderson <rth@redhat.com>, Jan Hubicka <jh@suse.cz>,
	gcc@gcc.gnu.org
Subject: Re: Tree-SSA self checking infrastructure
Message-ID: <20031119190152.GP16923@atrey.karlin.mff.cuni.cz>
References: <20031119174450.GI11681@kam.mff.cuni.cz> <20031119185648.GA31811@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20031119185648.GA31811@redhat.com>
User-Agent: Mutt/1.3.28i
X-SW-Source: 2003-11/txt/msg01014.txt.bz2

> On Wed, Nov 19, 2003 at 06:44:50PM +0100, Jan Hubicka wrote:
> >    b) verifying gimple types is almost impossible now.  The reason is
> >    ssa_useless_type_conversion.  Where we got about the plans to make it
> >    transitive and symteric?
> 
> I'm working on some of this this afternoon, verifying that the types
> match across ADDR_EXPR, INDIRECT_REF, ARRAY_REF only.  My interest 
> here comes out of wanting to fix ...

OK, so I am skipping this bit and wairing for your job :)
I am almost done with verify_stmts except for tree sharing, as I am
still not clear about the tree sharing rules.  (Did I mentioned it in
original email?)

> 
> >    c) I commonly got hit by the feature of gimple allowing almost
> >    arbitrarily complex constant operands.  What about restricting it
> >    into primitive constants +
> >    (plus_expr (nop_expr (addr_exr )) (integer_cst) as the most complex
> >    form?
> 
> ... this.  After my fold_stmt changes as of this morning, the only
> way (that I know of so far) of producing *(&var + 8) is for there to
> be a front-end bug wrt types.  Try to produce one of these from the
> C level and you'll get a cast which will prevent propagating the
> address into the dereference.
OKm I will update the tree.  I am not sure I understand your correctly.
How complex may the symbolic references look like now?
> 
> I've found more than a dozen such bugs so far.
> 
> At present, NOP_EXPRs are *not* valid gimple operands.  Believe it
> or not, but allowing that is even more complex than the PLUS_EXPR
> that we currently allow.
> 
> >    Doing fold_stmt as part of
> >    remove_useless_* uncovers latent bugs in fold_stmt.  Any plans on
> >    fixing the folders and any progress on this?
> 
> Try again.
Will do.

Honza
> 
> 
> r~