This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
RE: Java FUNCTION_DECL's have two bodies
- From: Andrew Haley <aph at redhat dot com>
- To: "Conway, Christopher L (Christopher)** CTR **" <cconway at lucent dot com>
- Cc: "gcc-java Mailing List (E-mail)" <java at gcc dot gnu dot org>
- Date: Thu, 24 Jun 2004 14:26:40 +0100
- Subject: RE: Java FUNCTION_DECL's have two bodies
- References: <F5F54E2EC6FEC14AAC3C9F28E8EE7EB808432210@nj9620exch002u.mh.lucent.com>
Conway, Christopher L (Christopher)** CTR ** writes:
> > > I'm working with a tool that uses the Tree-SSA output from gcj
> > > (version 3.5.0 20040607) and I'm surprised to see that Java
> > > FUNCTION_DECL's have two "body" attributes. One uses BLOCK and
> > > COMPOUND_EXPR treecodes for its infrastructure and the other uses
> > > BIND_EXPR and STATEMENT_LIST. I wonder if this is a bug, if it's
> > > possible to suppress one of these bodies from being produced, and
> > > if this will go away in a future version?
> >
> > This is a hangover from the way we used to do things.
> >
> > One (the BLOCK and COMPOUND_EXPR form) is converted to the other when
> > we gimplify: the "old" version shouldn't be present after then.
>
> But the two versions seem to be equivalent. Is there semantic
> information that will be lost if we use the new version
> pre-gimplification?
No. There's no strong reason why we shouldn't use BIND_EXPRs and
STATEMENT_LISTs in the gcj front end. It would mean less overhead.
Andrew.