This is the mail archive of the gcc-patches@gcc.gnu.org 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: problem building a GCJ-friendly GNU Crypto

From: Bryce McKinlay <bryce at mckinlay dot net dot nz>
To: tromey at redhat dot com
Cc: Roger Sayle <roger at eyesopen dot com>,Mark Wielaard <mark at klomp dot org>,raif at fl dot net dot au, <java at gcc dot gnu dot org>, <java-patches at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>
Date: Sun, 21 Sep 2003 21:45:19 +1200
Subject: Re: problem building a GCJ-friendly GNU Crypto

On Sunday, Sep 21, 2003, at 08:47 Pacific/Auckland, Tom Tromey wrote:

"Roger" == Roger Sayle <roger@eyesopen.com> writes:
Roger> I'm currently working on a patch to add an -fevaluation-order command Roger> line option to GCC, that sets a flag_evaluation_order variable that Roger> can be checked during constant folding to preserve left-to-right Roger> evaluation order of binary expressions. This can then be enabled by Roger> default by the java front-end, which should help make libbackend.a Roger> more java friendly.
What about just encoding the required sequencing information in the
trees somehow?  Actually, I thought we did that already.

Yeah - the Java evaluation order is encoded into trees using COMPOUND_EXPRs in force_evaluation_order (java/expr.c). I guess the problems with constant folding are because fold() gets called before force_evaluation_order does.

Regards

Bryce.

References:
- Re: problem building a GCJ-friendly GNU Crypto
  - From: Tom Tromey

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